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

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

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

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

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

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

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

Ответы

Ответ 1

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

Существует еще один вариант - PPerl.

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

Ответ 5

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

Ответ 6

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

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