Каждый вызов http_request ставит в очередь 1 запрос. Надо 10 параллельных запросов - надо выполнить 10 http_request. Но вызов $cv->recv блокирует дальнейшее выполнение, пока не будет вызван $cv->send (из колбека). И поэтому в очередь ставится всего 1 запрос. 

Вот из другого топика http://forum.vingrad.ru/topic-328733.html :

Вот примерно так. &cycle_run занимается стартом запросов и их отловом, а &run чисто за запросы отвечает и действия с ними.
В &cycle_run 2 цикла - while отвечает за перебор всех ссылок, а for - за создание запросов пачками по N штук.

Тут ещё немного инфы есть: http://likhatskiy.livejournal.com/1966.html
----------------------
Тот пример что я привёл ранее на Anyevent::HTTP не совсем правильный - он начинает обрабатывать 4 запроса, а остальные 96 запихивает в очередь, что не есть гуд.

Попробовал работать в AnyEvent::HTTP - очень понравилось  - на мой взгляд - действительно - это лучший модуль из всех паралелл, работает даже быстрее моего много поточного грабера - наверное действительно ДНС как-то кеширует (как в документации написано, если конечно я правильно перевел).
Единственный вопрос возник.
При работе с LWP::useragent, когда заголовки прописываешь, подделываешь не только заголовки как 

в посте выше 
{ "user-agent" => 'Opera/9.80 (X11; Linux x86_64; U; ru) Presto/2.8.131 Version/11.10' }
но и пишешь ему что $ua -> agent ('Opera/9.80 (X11; Linux x86_64; U; ru) Presto/2.8.131 Version/11.10')

Наверное это не одно и тоже, поскольку один хитрый сайт без прописания $ua-agent работать со мной отказался... :(

А как этого агента прописать используя модуль AnyEvent::HTTP , непонятно ...
или все таки 
в заголовке
{ "user-agent" => 'Opera/9.80 (X11; Linux x86_64; U; ru) Presto/2.8.131 Version/11.10' }
и 
$ua -> agent ('Opera/9.80 (X11; Linux x86_64; U; ru) Presto/2.8.131 Version/11.10')
это одно и тоже?

headers => { "user-agent" => '...' }, - это тот самый юзер-агент из header`а запроса, даже специально щас проверил.
Вроде там можно ещё какие то замуты производить с Anyevent::Header, но тут я х\з если честно.

Подскажите еще 
время от времени на одном из сайтов 
при грабке http::Anyevent
выдает код ошибки 596 хрен пойму что он означает, но чувствую, что ошибка происходит из за того, что Anyevent::Header не ждет долгого ответа от сайта (сайт нагружен и подтормаживает отвечать) - есть ли какой параметр чтобы ждать ответа подольше? Вроде у меня выставлено timeout => 5, но что это за таймаут? Ошибается только грабер на HTTP::Anyevent, а многопоточный который вытягивает контент при помощи LWP::UserAgent тянет нормально...

Вот что означает код
596 - errors during TLS negotiation, request sending and header processing.
но что это значит???

--
пробовал менять  timeout, точнее вообще не задавать его... написано что по умолчанию он 300 (непонятно в каких единицах - но как оказалось в секундах?)
так с таким дефолтным тайматом парсер вообще вешается на каком то моменте - это я так понимаю ждет какой то поток (меня об этом предупреждали) ну вообщем и все висит.

Если бы не было у меня моего многопоточного грабера я бы конечно подумал, что URL не отвечает - модуль ждет его timeout а затем по идее выдает код ошибки http. Но многопоточный грабер по всем этим ссылкам (граблю же один и тот же сайт) выдает 200 ОК и довольно быстро безо всякой задержки...

В чем же тут дело?

Это сообщение отредактировал(а) burakov - 21.5.2011, 22:35

Пожалуйста, одна тема - один вопрос.

timeout => 10 - это в секундах. дефолтное значение помоему 5 минут, что просто ТТ. С дефолтным значением парсер уходит в оооооочень долгое ожидание, по сути не совместимое с жизнью. Обычно хватает 5-10 на таймаут.
Код ошибки точно не помню, но некоторые не правильные урлы будут висеть пока не умрут по тайм ауту, например "http://site1.com/xxx/[email protected]" гарантировано звершается только по тайм ауту.

Похоже на ошибку установления https соединения.
Если сайт долго не отвечает это не должно тормозить всю программу. Если тормозит значит у вас что-то неверно в самой программе.

Это не чистая многопоточность, так что притормаживания в любом случае будут заметны на урлах с ошибками(которые умирают по таймауту).

С чего это вдруг? Тормоза будут заметны когда не будет справляться процессор или когда программа написана с ошибками, что в случае с событийно-ориентированным кодом очень легко.
Умирают по таймауту? Почему? Затянувшийся connect() или sysread()? Все эти операции производятся в неблокирующем режиме, поэтому не могут приостановить программу.

хрен поймешь
зависимость работы парсера от таймаут такая
если ставлю его = 5. то URL (одни и те же) идут то ответом 200, то 596,
если увеличиваю его по дефолту (то есть по сути сильно увеличиваю), то парсер подвисает.
Я пытаюсь Вас спросить - что это за параметр таймаут?
Я так для себя понял - что это время ожидания ответа от посланного http запроса, если в течении (когда =5) 5 секкунд ответа нет коннект отбрасывается с каким то кодом ошибки (ну пусть к примеру как у меня 596) так ли это?

Просто когда я использую многопоточный грабер на этом же сайта никакой видимой задержки нет (ну и потоки конечно отследить сложно - они ж в перемешку идут, может какой и подвисает на некоторое время).  Хотя нет - грабил данный сайт в один поток - тоже никаких задержек не было... что то все таки в модуле намудрили...

по поводу того, что сам парсер написан неправильно...

ошибки идут только на конкретном сайте, кроме этого парсер был обробован и локально и на двух других - таких проблем не было ... работало четко.
Могу выложить весь код парсера 200 строк

Это сообщение отредактировал(а) burakov - 22.5.2011, 21:24

burakov, приводите минимальный пример где проявляется эта ошибка. Тогда возможно и сможем сказать в модуле проблема или в вашем коде.

вот подпрограмма, которая берет ссылки из массива и тянет контент



Данный парсер был опробован на нескольких сайтах (и локально на денвере и в интернете) и только на этом возникают ошибки 596.

Не годится. Давайте код, который можно запустить и увидеть ошибки.

Кстате я тоже с таким сталкивался - был сайт, на котором паук сильно тупил. Сначала я пытался выцепить ссылки на которых тупит - оказались ссылки со встроенным видео плеером(хотя это никак не может ведь вызвать тормоза). Потом выцепил некоторые тупящие ссылки и ещё по 20 ссылок до и после для теста: ссылки работали нормально.
Короче, ситуация весьма неясная ... при 20 потоках грабер иногда убивает запросы по тайм-ауту, а при 1 потоке всё идёт ровно.
------------
Если урл убивается по тайм-ауту, то статус 597 (только что проверил)