![]() |
|
Модераторы: korob2001, ginnie |
![]()
|
|
| burakov |
|
|||
|
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 554 Регистрация: 28.7.2006 Репутация: нет Всего: нет |
Написал грабер на основе HTTP-Async-0.09.tar.gz вот инфу нашел отсюда http://www.snippy.ru/snippet/1708-perl-asi...-http-klientov/ И вообщем сравниваю свой многопоточный на threads Сделанный и новый на async: многопоточный реально работает быстрее - хотя количество потоков ставлю 20 - как по умолчанию параметр slots у этого async... По идее должно быть одинаково... Кто нибудь делал граберы на async, LWP::Parallel и т.п. сравнивал их производительность с реальным многопоточным решением??? Почему разница в скорости? |
|||
|
||||
| Pfailed |
|
|||
|
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 933 Регистрация: 19.7.2009 Репутация: 2 Всего: 39 |
Когда речь идёт о вводе/выводе использование потоков просто избыточно, особенно таких тяжёлых, как в perl.
Единственно для чего тут соит применить потоки это разбить процесс на кол-во потоков равных количеству процессоров, а в каждом уже использовать неблокирующий ввод/вывод. Такой вариант будет быстрее создания отдельного потока для каждого соединения. Плюс потребует гораздо меньше памяти. Составляйте минимальный пример обоих варинатов и показывайте. Там уже можно будет сказать почему первое быстрее второго или наоборот. |
|||
|
||||
| DurRandir |
|
|||
|
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 335 Регистрация: 27.9.2009 Репутация: 1 Всего: 17 |
Ололо! Модуль жжот) Это сообщение отредактировал(а) DurRandir - 12.5.2011, 13:21 |
|||
|
||||
| Pfailed |
|
||||
|
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 933 Регистрация: 19.7.2009 Репутация: 2 Всего: 39 |
Учитывая, что по дефолту poll_interval = 0.05, а sleep принимает только целочисленные аргументы, эта конструкция эквивалентна sleep(0), т.е. пустой конструкции. Другая более очевидная проблема этого модуля - синхронные запросы dns. А один из таких запросов в худшем случае может заблокировать всю программу на минуты. Один из модулей где решена эта проблема носит название AnyEvent::HTTP. |
||||
|
|||||
| burakov |
|
|||
|
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 554 Регистрация: 28.7.2006 Репутация: нет Всего: нет |
Ну не знаю, грабер на потоках работает так как ему и положено.
И так быстро как захочешь - поставил 2 потока - медленнее, поставил 20 - быстрее. Нареканий к нему нет. Хоть и потоки много памяти занимают и т.д. - главное работает как и задумывалось, а вот грабер на async ведет себя непонятно - ставишь ему slots = 20 - он вообще замирает, ставишь slots = 2 - вроде как работает быстрее, то есть ведет себя прямо противоположно ожидаемому. алгоритм грабера таков: 1. $async -> add (Стартовый URL) while ( my $res = $async -> wait_for_next_response) { 1. Сохраняю контент и ищу новые ссылки - пишу их в БД 2. Выбираю из БД ссылки и добавляю и делаю $async -> add (url) } Все вроде бы понятно - просто работает такая схема непонятно... poll_interval Задержка - 0,05 секунды - маленькая. ее можно в расчет не брать. Грабер виснет - на гораздо более продолжительное время... Синхронные запросы ДНС- в многопоточном грабере - тоже ведь ДНС синхронно запрашивается ???? однако все работает быстро и ничего не вешается на минуты и более... Сейчас, конечно посмотрю HTTP::Event, но все же... |
|||
|
||||
| Pfailed |
|
|||
|
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 933 Регистрация: 19.7.2009 Репутация: 2 Всего: 39 |
Еще немного посмотрел в HTTP::Async. Его вторая беда - блокирующийся connect.
Простой скрипт выводящий из строя всю Async'хронность
Сервер добавляемый вторым в данный момент выключен. В итоге весь скрипт зависает на неопределенное время. Итого: HTTP::Async для реальных задач использовать я не рекомендую. |
|||
|
||||
| burakov |
|
|||
|
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 554 Регистрация: 28.7.2006 Репутация: нет Всего: нет |
А что порекомендуете использовать для реальных задач?
Чтобы было уже проверено? и можно было отказаться от threads... (иногда таки дает ошибку памяти под WIN32, да и код посложнее) ParallelUserAgent-2.57.tar.gz? |
|||
|
||||
| DurRandir |
|
|||
|
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 335 Регистрация: 27.9.2009 Репутация: 1 Всего: 17 |
>Pfailed
Там есть импорт правильного слипа из Time::HiRes >burakov Был же уже назван модуль - AnyEvent::HTTP. Есть альтернативные подходы - к примеру, IO::Lambda. |
|||
|
||||
| Pfailed |
|
|||
|
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 933 Регистрация: 19.7.2009 Репутация: 2 Всего: 39 |
Ага точно, значит еще 1 минус в карму этому модулю |
|||
|
||||
| EcSYZ |
|
|||
![]() Шустрый ![]() Профиль Группа: Участник Сообщений: 79 Регистрация: 21.6.2007 Репутация: нет Всего: 1 |
threads можно юзать там, где нет сложных структур данны, т.е. где можно не слишком загонятся с синхронизацией.
В то время как Anyevent::HTTP позволяет вообще не задумываться не о какой синхронизации и работать почти как с однопоточным скриптом. Вот только если с threads ещё можно написать чтото через жопу и оно будет работать(возможно даже без глюков), то от anyevent быстро остановится, так как для этого достаточно если один коллбэк загнётся. У меня есть скрипт на Anyevent::HTTP и через него прошло уже как минимум 60к линков и без каких либо проблем. |
|||
|
||||
| EcSYZ |
|
|||
![]() Шустрый ![]() Профиль Группа: Участник Сообщений: 79 Регистрация: 21.6.2007 Репутация: нет Всего: 1 |
На счёт сравнение скорости:
Так как Anyevent(и все другие событийные машины) не чистая многопоточность, то в случае если один коллбэк задержится, то следующая пачка запросов будет ждать этот 1 коллбэк. Это конечно не особо приятно, но если вы пишите не паука для гугла который должен обходить милионы сайтов супер-пупер-мего быстро, то с этими небольшими потерями можно смирится. |
|||
|
||||
| burakov |
|
|||
|
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 554 Регистрация: 28.7.2006 Репутация: нет Всего: нет |
Ну не знаю,
на Anyevent::HTTP у меня ума не хватило, зато я адаптировал под себя ParallelUserAgent-2.57.tar.gz
Грабит локально с denwera (на этой же машине стоит). И не выдерживает никакой конкуренции по скорости с грабером на threads, который я думаю написан как раз через жопу на коленке - ибо я наверное по другому и не умею. Вообщем недоволен я остался LWP::Parallel. На Threads Выставил 5 потоков (больше нельзя ибо памяти не хватает Может кто поделится кодом с Anyevent::HTTP, чтобы сравнить скорости, уж больно в документации мало примеров ... Спасибо. |
|||
|
||||
| EcSYZ |
|
||||||
![]() Шустрый ![]() Профиль Группа: Участник Сообщений: 79 Регистрация: 21.6.2007 Репутация: нет Всего: 1 |
Генериться 100 ссылок. 4 потока:
10 потоков:
---------------------- На локалхосте больше 10 коллбэков оказывается без мазы, а для нета работал с 20-40. Это сообщение отредактировал(а) EcSYZ - 13.5.2011, 14:11 |
||||||
|
|||||||
| EcSYZ |
|
||||||
![]() Шустрый ![]() Профиль Группа: Участник Сообщений: 79 Регистрация: 21.6.2007 Репутация: нет Всего: 1 |
Тоже, но только на threads:
4 потока:
10 потоков:
PS: с LWP::UserAgent выходит ещё медленней, примерно на 100-400ms (подсчёт примерный). PS2: хотел ещё LWP::Parallel::UserAgent затестить, но он у меня даже не собрался ... Это сообщение отредактировал(а) EcSYZ - 13.5.2011, 16:46 |
||||||
|
|||||||
| burakov |
|
|||
|
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 554 Регистрация: 28.7.2006 Репутация: нет Всего: нет |
попробовал под себя адаптировать код AnyEvent::HTTP, но не получается... где то ошибка.
почему то колбэк (sub) отрабатывает один раз... подозреваю, что это из за неправильно расставленных $cv->send; #??? $cv->recv; #??? Но я так из описания модуля и не нашел этих методов на cpan.org что они делают и как их использовать, чтобы все работало... А может дело и не в этом... В чем ошибка? Спасибо.
|
|||
|
||||
![]()
|
| Правила форума "Perl: CGI программирование" | |
|
|
Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, korob2001, sharq. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | Perl: разработка для Web | Следующая тема » |
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |