Стоит ли использовать Perl CGI :: Fast на Apache 2? - PullRequest
Новая
       31

Стоит ли использовать Perl CGI :: Fast на Apache 2?

0 голосов
/ 13 декабря 2011

Я знаю, что это звучит как вопрос для ServerFault , но я знаю, что разработчики часто получают вину, когда серверы борются, поэтому я подумал, что публикация здесь может быть полезна людям, которые все еще используют Perl в сети.

ИСТОРИЯ:

У нас были серьезные проблемы с перестал работать на нашем старом сервере Apache, поэтому мы решили перейти на Apache 2. Новый сервер работает намного лучше, нетотрицая это.Однако тесты показывают, что при большой нагрузке (~ 100 пользователей в минуту) несуществующие процессы начинают быстро нарастать на сервере, и при использовании SSH становится ясно, что эти процессы используют ЦП.Чтобы преодолеть эти проблемы, мы решили реализовать CGI :: Fast , который является типом FastCGI в Perl .Имея это на месте, зомби исчезли, однако с точки зрения производительности сервер справляется не лучше.

Результаты привели меня к выводу, что на самом деле нет смысла в реализации CGI :: Fast если Apache 2 будет эффективно восстанавливать ресурсы в любом случае.

Кто-нибудь из вас пришел к другому заключению?

Ответы [ 3 ]

7 голосов
/ 13 декабря 2011

По моему мнению, не стоит переходить ни к чему, кроме решения PSGI / Plack в 2011 году, независимо от любых других деталей, которые вы упомянули.

  • * Plack экосистема намного лучше , чем FastCGI.(преимущество)
  • Вы можете развернуть на гораздо большем количестве серверов, чем FastCGI поддерживает .(преимущество)
  • Вы можете запускать сценарии CGI без изменений, например, Plack :: App :: CGIBin , тогда как CGI :: Fast требует переписывания.(преимущество)
  • Перезапись программы CGI для соответствия PSGInterface требует чуть больше усилий, чем переписывание ее в CGI :: Fast.(недостаток)
4 голосов
/ 13 декабря 2011

FastCGI работает быстрее, чем обычный CGI, потому что Apache не должен загружать perl для каждого нового запроса.Однако сценарии необходимо переработать, чтобы исключить предположение, что они выполняются один раз для каждого запроса.Сценарий FastCGI в своей основе обычно представляет некоторый тип цикла событий, обрабатывающий запросы по мере их поступления.

Вы можете использовать CGI :: Fast для простых сценариев CGI, не переделывая сценарий вокруг цикла событий, но вытаким образом вы теряете «быструю» часть FastCGI, поскольку perl по-прежнему нужно запускать один раз для каждого сценария.

FastCGI также обеспечивает большое преимущество, только если большая часть вашего CGI-скрипта загружает Perl или выполняет его.кодДля многих веб-приложений это правда.Тем не менее, если вашему сценарию необходимо выполнить большую работу для каждого запроса, например, чтобы накладные расходы на загрузку perl были небольшими, вы не увидите большого выигрыша в производительности при использовании FastCGI.

1 голос
/ 13 декабря 2011

CGI

Это было слишком неэффективно для всего, кроме небольших сайтов. CGI порождает новый процесс для каждого входящего запроса на выполнение скрипта, очень ресурсоемкий и неэффективный способ выполнения задач. Неудивительно, что со временем оно исчезло, поскольку веб-приложения стали более сложными.

FastCGI был введен, чтобы избежать некоторых проблем с запуском языков внутри процесса Apache, а также избежать неэффективности CGI.

Приложение FastCGI выполняется за пределами веб-сервера (Apache или другого) и ожидает запросов от веб-сервера с помощью сокета. Веб-сервер и приложение FastCGI могут даже находиться на отдельных физических машинах и обмениваться данными по сети.

Поскольку веб-сервер и процессы приложений разделены, возможна лучшая изоляция.

...