PHP или ванильный Perl CGI быстрее?

Question

Я разрабатываю веб-приложение для сервера общего хостинга Apache. Я уже написал некоторый код на Perl, но недавно обнаружил, к моему удивлению, провайдер виртуального хостинга не предоставляет mod_perl или способ его установки.

Меня немного беспокоит, что запуск веб-приложения на Perl через CGI без mod_perl сделает его очень медленным? Должен ли я вместо этого переключить весь свой код на PHP, это будет быстрее?

Причина, по которой я выбрал Perl, в том, что я очень хорошо знаком с Perl, а не с PHP. Также я хотел иметь возможность использовать мои библиотеки Perl за пределами веб-разработки.

Так что, если у кого-то из вас есть опыт веб-разработки Apache, не могли бы вы пролить свет на то, в каком направлении мне идти.

Ради этого вопроса, скажем, веб-приложение будет получать 500+ посещений в день.

Что было бы быстрее PHP или Perl без mod_perl?

Заранее спасибо за помощь.

Answer 1

Всего лишь 500 обращений в день, вы можете написать свой код практически во всем, и вам не придется беспокоиться о замедлении работы. 500 просмотров в день выравнивается примерно до 1 страницы каждые 3 минуты. Даже если предположить ненормальное распределение посещений, вам не стоит беспокоиться об этом при таком небольшом количестве трафика.

Answer 2

PHP будет быстрее.

Тем не менее, при наличии только 500 обращений в день использование cgi не будет проблемой. Даже с 500 ударами в час.

Answer 3

Многое зависит от вашей архитектуры. Современные платформы Perl плохо подходят для использования в качестве CGI (длительное время запуска). Если вы используете CGI, Catalyst, вероятно, плохая идея. Тем не менее, используя классическую архитектуру, она должна быть вполне управляемой.

Answer 4

Если ваш общий хост не использует PHP как приложение CGI (не mod_php или FastCGI), PHP почти ¹ всегда будет быстрее. Хотя Perl, работающий как CGI, вероятно, может обрабатывать ваши 500 обращений в день, приложение / страница, разработанная с помощью CGI, будет вялым.

CGI работает, порождая новый процесс для запуска вашей программы для каждого запроса. И приложения mod_php, и приложения FastCGI смягчают это, порождая набор процессов и затем используя их для запуска вашего приложения. Другими словами, новые процессы не создаются для каждого запроса. (Это упрощенное объяснение, пожалуйста, не используйте в курсовой работе CS. Для получения дополнительной информации см. Документы mod_php и FastCGI)

1. Вы могли бы привести патологические примеры, которых не было бы, но тогда вы были бы тем человеком, который придумал бы патологические примеры вещей, и никто не хочет этого

Answer 5

Для объема трафика, который вы просматриваете, Perl с vanilla CGI не должен быть проблемой, хотя я бы поддержал более ранние рекомендации, чтобы проверить FastCGI как еще один вариант, который может предоставить ваша служба хостинга.

Или другой вариант - поискать другую хостинговую компанию ...

Answer 6

Расширяя сказанное Аланом Штормом , вы можете вместо этого использовать Perl с FCGI.

FCGI работает, имея своего рода автономный сервер, если хотите, демон, который соединяется с вашим веб-сервером по протоколу FCGI и делегирует / отправляет запросы.

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

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

FastCGI / FCGI должен быть доступен на значительно большем количестве хостов, чем обычный старый mod_perl, поскольку приложения FCGI не зависят от веб-сервера, а некоторые веб-серверы реализуют PHP с помощью утилиты fcgi.

И я немного поэкспериментировал с веб-сервером FCGI, и предварительные тесты говорят, что он может обрабатывать как минимум 500 запросов / с, что намного быстрее, чем вышеупомянутые проблемы 500 / день или 500 / час.

Answer 7

Скорость не должна быть вашей заботой. Оба языка подходят для веб-приложений.

Answer 8

Возможно взломать поддержку fastcgi в учетной записи хостинга, которая его не поддерживает. Я скомпилировал библиотеку fastcgi с префиксом установки, равным домашнему каталогу учетной записи хостинга. Затем я синхронизировал его и настроил катализатор для использования маленького моста cgi-fcgi. Это сработало хорошо. Красиво и быстро, потому что мост cgi - это просто маленький исполняемый файл. Процесс катализатора сохранился на заднем плане очень хорошо.

Answer 9

Ответ у всех на уме: кого это волнует. 500 запросов в день - ничто.

Просто используйте то, что быстрее всего для внедрения / сопровождения и продвижения вперед.

Answer 10

Для более легких веб-фреймворков, которые будут работать с CGI, взгляните на ....

• Присев
• CGI :: Application
• CGI :: Ленивый