Какие критерии следует использовать для оценки Perl-сервера приложений (замена mod_perl)?

Question

Короткая версия:

Какие критерии следует использовать для оценки возможных кандидатов на «сервера приложений» Perl (замена mod_perl)?

Мы ищем какую-то структуру, которая позволит выполнения различных Perl программ повторно (как услуга) без затрат:

1. повторно launcing PERL интерпретатор один раз в каждом исполнении

2. загрузки/компиляции Perl модулей один раз в исполнении

(оба из которых являются преимущества, которые работает mod_ Perl предоставляет)

Примечания:

• Мы не очень заботиться о каких-либо дополнительных преимуществ, предоставляемых по mod_perl слишком много, таких как глубокая интеграция Apache.

• Это будет чистый сервер приложений, то есть нет необходимости в каких-либо конкретных веб-функциях (это не проблема, если сервер приложений предоставляет его, просто не понадобится).

• Мы, конечно, рассмотрим очевидные критерии (необработанная скорость, готовность к производству, активная разработка, возможность запуска на OS, о котором мы заботимся). Меня интересуют менее тривиальные и тонкие вещи, которые мы можем пожелать от такой платформы/сервера.

фона:

В $ работа, власть имущие решили, что они хотят, чтобы заменить текущую ситуацию (простые WebApps разрабатываются в Embperl и развертываются с помощью Apache/mod_perl).

Было принято решение использовать (доморощенную) систему MVC, которая будет иметь передний конец Java Spring для представления; и Контроллер будет обрабатывать внутренние запросы на услуги для каждого приложения, которые выполняют обязанности по модели (не зацикливайтесь на деталях этого - это не очень важно для основного вопроса).

Одним из вариантов для внутренних служб является Perl, так что мы можем использовать все существующие существующие Perl IP (библиотеки, веб-серверный код) в будущем и не должны переносить 100% его на Java.

Резюмируя:

| View | Model/app | Model loaded/executed by:       | 
================================================================================ 
OLD | Empberl | Model.pm | mod_perl has Model.pm loaded, called from view.epl | 
NEW | Java | Model.pm | perl generic_model.pl -model Model (does "require") | 
================================================================================ 

Теперь, те из вас, кто сделал веб-разработки на Perl некоторое время, сразу же заметит наиболее вопиющие проблемы с новым дизайном:

| Perl interpreter starts | Perl modules are loaded and compiled | 
======================================================================= 
OLD | Once per mod_perl thread | Once per mod_perl thread 
NEW | Once per EVERY! request | Once per EVERY! request    | 
======================================================================= 

Другими словами , в новой модели у нас больше не имеют каких-либо преимуществ производительности, предоставляемых mod_perl в качестве постоянного контейнера приложений на стороне сервера!

Поэтому мы рассматриваем возможные контейнеры приложений для обслуживания той же функции.

(в качестве примечания стороны, да, мы думали просто запустить экземпляр Apache с mod_perl как таковой в контейнере приложения как жизнеспособную возможность. Однако, поскольку веб-функциональность не требуется, я бы хотел увидеть, любые другие варианты могут соответствовать счету).

Answer 1

Я думаю, вы уже определили, что вам нужно знать и что тестировать: время выполнения против памяти. Вам также необходимо оценить гибкость и простоту развертывания, которые вы получаете с помощью mod_perl, и большой выигрыш в сохранении полезности программного обеспечения, которое вы уже разработали (и накопленного опыта ваших сотрудников). Помните, что вы можете легко отделить сервисы от процессора и компьютера, если ваш новый интерфейс будет разговаривать с вашими приложениями внутри вашей собственной сети. Многое зависит от того, как «веб-иш» вы можете делать свои услуги, и если они могут быть эффективно «демонанизированы». Конечно, есть много способов, чтобы веб-интерфейсы могли общаться с другими службами, а perl может обрабатывать почти все из них ... TIMTOWTDI.

Поскольку вы упоминаете «tuits» (т.е. «живой силы») в качестве ограничения, возможно, лучший подход в краткосрочной перспективе создать отдельный apache - mod_perl экземпляр в качестве «контейнера приложения» и запускать приложения (так как они уже так хорошо работают, это правильно?). В конце концов, apache (и mod_perl) хорошо известны, испытаны на битву, и в высшей степени настраиваются и настраиваются. Варианты развертывания довольно гибкие (одна и та же машина, разные машины, отказоустойчивость, балансировка нагрузки, облако, локальные, виртуальные машины), и они также хорошо протестированы.

Как только вы получите этот бег, вы можете начать экспериментировать с различными подходами к «низкой рабочей силе», чтобы магически демонизировать ваши приложения и службы без apache. Plack и Starman, Mojolicious:: - это еще одна конструкция, которая способна работать с веб-разъемами JSON и т. Д. (И Plack). Они тоже были хорошо протестированы, но, возможно, менее знакомы, чем mod_perl и Apache. Тем не менее, если вы являетесь магазином perl, вам не должно быть трудно работать с этими «современными» инструментами. Однажды, если вы в конечном итоге получите больше ресурсов, вы можете создать сложную сетевую платформу для всех своих услуг на основе perl и использовать все классные «новые» (или, по крайней мере, более новые, чем mod_perl) вещи на CPAN, такие как POE, Plack, и т. д. Возможно, вам будет очень интересно разрабатывать классные вещи, когда вы решаете свою деловую проблему.

Чтобы прояснить мой предыдущий комментарий: Ubic (см Ubic на MetaCPAN) может демон (и, таким образом, прекомпиляция) ваши perl инструментов и предлагают некоторые средства мониторинга и управления, которые приходят бесплатно рамки для. Имеется один модуль Ubic, предназначенный для использования с Plack под названием Ubic::Service::Plack. Само по себе Ubic не обеспечивает легкое решение для вашего нового приложения Java/Swing, чтобы поговорить с вашими приложениями perl, но это может помочь управлять/контролировать любое решение, с которым вы сталкиваетесь.

Удачи и получайте удовольствие!

Answer 2

Starman - это высокопроизводительный веб-сервер PSGI/Plack с высоким качеством, который может использоваться в этом контексте. Легко создать приложение REST, которое обслуживает объекты без состояния JSON (это простой вариант использования).

Starman является производство готовых серверов и это очень легко установить набор экземпляров Starman за обратным прокси (this SO question may helps you), для масштабирования целей

Answer 3

Вы можете создать простой демон, используя HTTP::Daemon, и есть все преимущества компиляции необходимых частей вашего кода позже (require), или заранее, до запуска демона.