Как я могу улучшить производительность Moose в непостоянных процессах CGI?

Question

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

В отличие от этого, когда мы используем постоянную систему процессов (например, FCGI), эти издержки запуска исключаются (или, скорее, только один раз), и все хорошо. Проблема в том, что мы не можем гарантировать, что весь наш код будет всегда выполняться в постоянном процессе.

Мы исследовали использование Mouse в качестве замены Moose с ограниченной функциональностью, но, как выясняется (как упоминалось в этот ответ ), этот вариант не подходит. Любые библиотеки, которые мы пишем для работы с Moose, не будут работать с мышью тонкими, но важными способами. И мы действительно не хотим разветвлять все наши модули, чтобы мы могли поддерживать как Moose в постоянной среде, так и Mouse для "ванильного" CGI.

Учитывая это, у нас есть следующие опции:

1. Форки наших собственных модулей для работы с Moose или Mouse, в зависимости от ситуации. (Тьфу!)
2. Разрабатывать только наши модули для FCGI / Moose . Больше не поддерживаю "ванильный" CGI. Если нам придется писать непостоянные сценарии, они не смогут использовать наши собственные модули.
3. Не используйте Moose или Mouse , но некоторые другие объектные рамки.

Какой вариант лучше? Мы склоняемся к 2 прямо сейчас, и мы просто смиримся с этим, если нам нужно будет запустить что-то вроде ванильного CGI. Как насчет других фреймворков? Есть ли что-нибудь более легкое, на что мы должны смотреть?

Answer 1

Я бы предпочел отказаться от поддержки CGI ванили. Хостинг FCGI действительно дешев в наши дни, и нет никаких причин потворствовать ванильному CGI (IMO), потому что он только подтверждает мнение, что Perl медленный. Но если вы не можете избежать этого, вы можете использовать что-то вроде Object :: Tiny . Но если вам нужны роли, ограничения, метапрограммирование и все прочие прелести, которые предоставляет Moose, вам не повезет, если вы не отбросите ванильный CGI.

Answer 2

Вы можете написать серверное приложение с помощью Moose, а затем написать очень маленькие, простые CGI-скрипты, которые запрашивают серверную часть.

+-------+    +--------------+
| Small |===>|  Persistent  |
|  CGI  |<===| Moose Server |
+-------+  ^  +--------------+
           |
         Socket
       Connection

Это более или менее то, что делает FCGI, поэтому может иметь смысл использовать FCGI.

С другой стороны, может быть реальная выгода от того, что сервер, не являющийся cgi, может иметь ЛЮБОЙ абстрактный интерфейс, прикрепленный по мере необходимости.

Например, если вы используете сокеты TCP (или UDP), то вы можете сделать так, чтобы нативное настольное приложение получало ту же часть, что и CGI.

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

Answer 3

Мое предложение состоит в том, чтобы перейти к варианту № 2, а затем помочь нам реорганизовать Moose, чтобы CGI стал жизнеспособным. В настоящее время fREW работает над набором тестов Moose, чтобы включить проект MooseX :: Antlers, который должен уменьшить большую часть накладных расходов, что означает, что Moose непригоден для среды CGI.

Мэтт Траут (mst), человек, который в настоящее время стоит за MooseX :: Antlers, выразил желание иметь возможность запускать приложения в среде CGI в случае необходимости. Я бы посоветовал остаться с FCGI и приставать к нему за то, что вы можете сделать, чтобы помочь!

Answer 4

Основная идея App::Persistent, pperl, SpeedyCGI и, возможно, некоторых других заключается в том, что процесс компиляции вашей Perl-программы для Байт-код выполняется только один раз, и после этого при вызовах используется какое-то кэширование. Поскольку говорят, что у Moose довольно много штрафов за время компиляции, я сначала попробую этот подход.

Я успешно использовал pperl для рисования большого количества графиков MRTG в древней системе примерно в 2001 году. Программа Perl была выполнена для каждого графика, который был довольно затратным - это, вероятно, сопоставимо с вашим CGI сценарий.

Answer 5

Джонатан Рокуэй написал о APP :: Peristent (что, как ни странно, не в CPAN) несколько месяцев назад. Я не использовал его, но, основываясь на его вышеупомянутом посте в блоге, похоже, что он обеспечивает довольно прозрачную архитектуру сервер-клиент, в которую можно обернуть фактическую обработку CGI.

Answer 6

Существует также другая опция - PPerl .

Я никогда не использовал это, но это определенно выглядит интересно. И тот, кто написал это (Matt Sergeant aka baud) - это дает вам практически гарантию хорошего качества кода.