Краткая версия:
Какие критерии следует использовать для оценки возможных кандидатов на сервер приложений Perl (замена mod_perl)?
Мы ищем какую-то структуру, которая позволит выполнять различные программы Perl повторно (как сервис) без затрат:
перезапуск Perl-интерпретатора один раз за каждое исполнение
загрузка/компиляция модулей Perl один раз за выполнение
(оба из которых являются преимуществами, предоставляемыми программой mod_perl)
Примечания:
Мы не очень заботимся о каких-либо дополнительных преимуществах, предоставляемых mod_perl, таких как глубокая интеграция с Apache.
Это будет чистый сервер приложений, то есть нет необходимости в каких-либо конкретных веб-функциях (это не проблема, если сервер приложений предоставляет его, просто не понадобится).
Мы, конечно, рассмотрим очевидные критерии (необработанная скорость, готовность к производству, активная разработка, возможность запускать на OS, о котором мы заботимся). Меня интересуют менее тривиальные и тонкие вещи, которые мы можем пожелать от такой среды/сервера.
Фон:
В $work полномочия, которые будут решаться, чтобы они захотели заменить текущую ситуацию (простые 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 Web-разработкой какое-то время, сразу заметили самую вопиющую проблему с новым дизайном:
| 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 как такового в контейнере приложения, что является жизнеспособной возможностью. Однако, поскольку веб-функциональность не требуется, я бы хотел увидеть, другие варианты могут соответствовать законопроекту).
Starman - это высокопроизводительный веб-сервер PSGI/Plack, который может использоваться в этом контексте. Легко построить приложение REST, которое обслуживает объекты JSON без состояния (это простой пример использования).
Starman - готовый к производству сервер, и очень легко установить набор экземпляров Starman за обратным прокси (этот вопрос может помочь вам), для масштабирование
Я думаю, вы уже определили, что вам нужно знать и что тестировать: время выполнения против памяти. Вам также необходимо оценить гибкость и простоту развертывания, которые вы получаете с помощью 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, но это может помочь управлять/контролировать любое решение, с которым вы сталкиваетесь.
Удачи и получайте удовольствие!
Вы можете создать простой демон с помощью HTTP:: Daemon и получить все преимущества компиляции необходимых частей вашего кода позже (require), или заранее, до запуска демона.