14 января 2011 г. 15:21 пользователь Dmitry Simonov <[email protected]>написал:
> А зачем тебе хорошая технология AnyEvent, которая вообще говоря не > заточена под интерфейсные работы? > может я и правда решаю что-то не так, раз такие вопросы возникают в данный момент есть такая задача: имеем прокси сервер с поддержкой ICAP. нужно по своим правилам модифицировать/мониторить весь проходящий сквозь прокси http-траффик. сперва пошли по обычному пути: каждый ICAP-запрос - обрабатывается в префорке (Net::Serer). префорка вычитывает заголовки запроса и дергает функцию обработчик с вычитанным, которая решает что делать с запросом: менять или оставлять как есть. ну и в БД логгирует и по правилам выбранным из БД принимает решения/делает модификации. так вот, эта модель получается довольно накладной по ресурсам. тесты показывают что вариант на базе AnyEvent::Socket (tcp_server) к ресурсам сильно менее требователен выходит (особенно если учесть что 99% контента проходит сквозь это без модификации либо только с модификацией заголовков). проблемы начинаются когда надо полученный ответ сервера распарсить, модифицировать, собрать обратно в новый ответ. Блокирующих операций при этом нет (БД в AnyEvent опять же), но парсинг/обработка занимают иногда время что много клиентов скапливается в очереди на обработку. тут собственно два пути: экстенсивный - увеличение числа процессов слушающих соединения от клиентов. и интенсивный - вынос парсеров в отдельные процессы (возможно даже на отдельные хосты, в перспективе).
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
