<br><br><div class="gmail_quote">14 января 2011 г. 15:21 пользователь Dmitry Simonov <span dir="ltr"><<a href="mailto:dsimonov@gmail.com">dsimonov@gmail.com</a>></span> написал:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
А зачем тебе хорошая технология AnyEvent, которая вообще говоря не<br>
заточена под интерфейсные работы?<br></blockquote></div><br>может я и правда решаю что-то не так, раз такие вопросы возникают<br><br>в данный момент есть такая задача:<br><br>имеем прокси сервер с поддержкой ICAP.<br>нужно по своим правилам модифицировать/мониторить весь проходящий сквозь прокси http-траффик.<br>
<br>сперва пошли по обычному пути: каждый ICAP-запрос - обрабатывается в префорке (Net::Serer). префорка вычитывает заголовки запроса и дергает функцию обработчик с вычитанным, которая решает что делать с запросом: менять или оставлять как есть.<br>
ну и в БД логгирует и по правилам выбранным из БД принимает решения/делает модификации.<br><br>так вот, эта модель получается довольно накладной по ресурсам.<br><br>тесты показывают что вариант на базе AnyEvent::Socket (tcp_server) к ресурсам сильно менее требователен выходит (особенно если учесть что 99% контента проходит сквозь это без модификации либо только с модификацией заголовков). проблемы начинаются когда надо полученный ответ сервера распарсить, модифицировать, собрать обратно в новый ответ. Блокирующих операций при этом нет (БД в AnyEvent опять же), но парсинг/обработка занимают иногда время что много клиентов скапливается в очереди на обработку. тут собственно два пути: экстенсивный - увеличение числа процессов слушающих соединения от клиентов. и интенсивный - вынос парсеров в отдельные процессы (возможно даже на отдельные хосты, в перспективе).<br>