Есть сервер на котором висит один CGI скрипт написанный на perl'e. К нему порядка 3 тыс обращений в минуту и похоже это потолок для него. Хотелось б как-то увеличить эффективность работы скрипта. Не раз встречал советы использовать mod_perl к апачу, но ни разу с ним не работал и поэтому возникает следующий вопрос:

увеличит ли скорость работы скрипта mod_perl и сильно переписывать его придётся?
Он имеет примерно следующую структуру:

1. получение и анализ параметров запроса GET
2. проверка наличия куки и запись в него одной строчки данных
3. получение данных от сишной программы $res=`/usr/local/bin/my_prog` - помоему самый тормозной момент: прога сама летает, но из perl'a уж как-то медленно вызывается
4. сброс результатов работы в лог-файл (за день до 600М выростает)

• поможет ли mod_perl ?,perece, 17:42 , 20-Авг-06

>Есть сервер на котором висит один CGI скрипт написанный на perl'e. К
>нему порядка 3 тыс обращений в минуту и похоже это потолок
>для него. Хотелось б как-то увеличить эффективность работы скрипта. Не раз
>встречал советы использовать mod_perl к апачу, но ни разу с ним
>не работал и поэтому возникает следующий вопрос:
>
>увеличит ли скорость работы скрипта mod_perl и сильно переписывать его придётся?
>Он имеет примерно следующую структуру:
>
>1. получение и анализ параметров запроса GET
>2. проверка наличия куки и запись в него одной строчки данных
>3. получение данных от сишной программы $res=`/usr/local/bin/my_prog` - помоему самый тормозной момент:
>прога сама летает, но из perl'a уж как-то медленно вызывается
>4. сброс результатов работы в лог-файл (за день до 600М выростает)
если сишный компонент таки присутствует, почему не научить его же делать 1,2 и 4 и исключить перл вообще, и лишний exec в частности?
(без каких-либо библиотек писать cgi на C немного гиморно, но всеже реально. библиотек много и разных. могу поделиться своей - "без излишеств", тока разбор urlencoding и GET/POST запросов)

дальше можно развить мысль, преобоазовав прогу на C в собсно сервер - CGI executive, и поправив ссылки (пусть скажем основной порт 80, а экзекутив слушает 81). в таком варианте предела производительности достичь очень трудно. даже если не получится написать single-threaded (на poll/select), то даже fork - не очень "дорогая" операция по сравнению с exec'ом (учитывая copy-on-write технологию ныне применяемую).

\^P^/