PHP или ванильный Perl CGI быстрее?
Я разрабатываю веб-приложение для сервера общего хостинга Apache. Я уже написал код на Perl, но недавно, к своему удивлению, обнаружил, что провайдер виртуального хостинга не предоставляет mod_perl или способ его установки.
Я немного волновался, что запуск веб-приложения Perl через CGI без mod_perl сделает его очень медленным? Должен ли я вместо этого переключить весь свой код на PHP, это будет быстрее?
Причина, по которой я выбрал Perl в первую очередь, заключается в том, что я хорошо знаком с Perl больше, чем с PHP. Также я хотел иметь возможность использовать свои библиотеки Perl вне области веб-разработки.
Итак, если у кого-то из вас есть опыт веб-разработки на Apache, не могли бы вы пролить свет на то, в каком направлении мне следует двигаться.
Ради этого вопроса, допустим, веб-приложение будет получать 500+ обращений в день.
Что было бы быстрее PHP или Perl без mod_perl?
Заранее спасибо за помощь.
Ответы 11
PHP будет быстрее.
Однако, имея всего 500 обращений в день, использование cgi не будет проблемой. Даже с 500 обращениями в час.
хорошо, спасибо, я только что слышал, насколько mod_perl лучше, чем cgi perl, я, вероятно, не осознавал, что cgi perl по-прежнему чертовски быстр.
Было бы точнее сказать, что модуль Apache будет быстрее, чем CGI - это не совсем языковая проблема.
Скорость не должна вас беспокоить. Оба языка подходят для веб-приложений.
Если ваш общий хост не запускает PHP как приложение CGI (не mod_php или FastCGI), PHP почти всегда будет быстрее 1. В то время как Perl, работающий как CGI, вероятно, мог бы обрабатывать ваши 500 обращений в день, приложение / страница, разработанное с помощью CGI, будет медленным.
CGI работает, порождая новый процесс для запуска вашей программы для каждого запроса. И mod_php, и приложения FastCGI смягчают это, создавая набор процессов, а затем используя их для запуска вашего приложения. Другими словами, для каждого запроса не создаются новые процессы. (Это упрощенное объяснение, пожалуйста, не используйте его в курсовой работе CS. Дополнительную информацию см. В документации mod_php и FastCGI)
- Вы могли бы придумать патологические примеры там, где этого не было бы, но тогда вы были бы тем человеком, который придумывал бы патологические примеры вещей, а это никому не нужно.
mod_php фактически встраивает интерпретатор PHP в Apache. Это ускоряет выполнение PHP, но вам действительно следует установить кеш кода операции, если вы заботитесь о скорости.
Вы знаете, если вы сравниваете яблоки с яблоками, то есть mod_perl с mod_php или perl CGI с PHP CGI, perl обычно несколько быстрее. Конечно, не намного быстрее, но немного. Попробуйте поискать по запросу "перестрелка по языку программирования".
Я считаю, что это касается сравнения яблок с яблоками, но исходный вопрос плаката касался общего хостинга, а большинство общих хостов не поддерживают mod_perl,
В то же время сейчас уже не 1993 год, fork() действительно не такой медленный и громкость здесь не требует ничего, кроме CGI.
Расширяя то, что Алан Сторм сказал, вы могли бы вместо этого использовать Perl с FCGI.
FCGI работает, имея своего рода автономный сервер, демон, если хотите, который соединяется с вашим веб-сервером через протокол FCGI и делегирует / отправляет запросы.
Это быстрее, чем обычный CGI, так как он имитирует своего рода модель «сервлета», приложение является постоянным, и нет необходимости в новой инициализации при каждом вызове, как в случае с обычным CGI.
Я еще не научился делать это сам, но полагаю, что у Catalyst есть такая возможность, так что остается только научиться копировать это.
FastCGI / FCGI должен быть доступен на значительно большем количестве хостов, чем простой старый mod_perl, поскольку приложения FCGI не зависят от веб-сервера, а некоторые веб-серверы реализуют PHP через утилиту fcgi.
И я немного поэкспериментировал с веб-сервером FCGI, и предварительные тесты показали, что он может обрабатывать не менее 500 запросов / с, что намного быстрее, чем указанные выше проблемы 500 / день или 500 / час.
Вот документы FastCGI Catalyst ... search.cpan.org/dist/Catalyst-Manual/lib/Catalyst/Manual/…
Многое зависит от вашей архитектуры. Современные Perl-фреймворки не подходят для использования в качестве CGI (длительное время запуска). Если вы используете CGI, Catalyst, вероятно, будет плохой идеей. Тем не менее, при использовании классической архитектуры это должно быть вполне управляемо.
Всего 500 обращений в день, вы можете написать свой код практически на чем угодно и не беспокоиться о замедлении работы. 500 просмотров в день превращаются примерно в 1 страницу каждые 3 минуты. Даже если предположить ненормальное распределение попаданий, вам не стоит особо беспокоиться об этом при таком небольшом количестве трафика.
Вы должны беспокоиться об этом до такой степени, что не решите использовать что-либо в зависимости от одной из более мощных сред, таких как Catalyst, Moose или, может быть, даже DateTime. Такое нечастое обращение к странице не означает, что время загрузки измеряется в секундах.
@ysth + когда-нибудь ты захочешь узнать, как это сделать сексуально. Я предполагаю, что от 500 посещений сайтов в день не так много денег!
Для объема трафика, на который вы смотрите, Perl с ванильным CGI не должен быть проблемой, хотя я бы поддержал предыдущие рекомендации, чтобы проверить FastCGI как еще один вариант, который может предоставить ваш хостинг.
Или другой вариант - поискать другую хостинговую компанию ...
Для более легких веб-фреймворков, которые будут работать с использованием CGI, обратите внимание на ....
Ответ, который у всех на уме: кого это волнует. 500 запросов в день - это пустяк.
Просто используйте то, что быстрее, чтобы реализовать / поддерживать и двигайтесь дальше.
Каждый хороший разработчик программного обеспечения должен заботиться. Я использовал 500+ в качестве примера, мне бы очень понравилось, если бы мой сайт получил 100000, даже если это 1 попадание, он должен работать эффективно, если только не потребуется какое-то нелепое количество времени, чтобы сделать его более эффективным.
Вас волнует, получает ли ваш сайт 500 посещений в день и на каждые полсекунды тратится запуск вашего CGI-приложения по сравнению с запуском чего-то, предварительно загруженного в mod_ {php, perl}, потому что каждый пользователь решит, что ваш сайт медленный, и вы никогда не добраться до этих 100000.
@ SukhbirS.Dadwal - Отличный разработчик сделает то, что написано на плакате, выполнит работу правильно и в рамках бизнес-требований и пойдет дальше. Когда требования изменятся для поддержки нескольких тысяч одновременных сеансов, тогда подходите к этому моменту. Тратить время, силы, ресурсы и деньги на решение проблемы скорости CGI, которой просто не существует, просто расточительно.
@ SukhbirS.Dadwal Если ваш сайт так сильно разрастется, то в конечном итоге будет иметь значение гибкость, которую вы должны будете заставить сайт продолжать развиваться, чтобы адаптироваться к потребностям пользователей. И в этом отношении выбор языка и фреймворка важнее скорости.
Можно взломать поддержку fastcgi в учетной записи хостинга, которая ее не поддерживает. Я скомпилировал библиотеку fastcgi с префиксом установки, установленным на то же значение, что и домашний каталог в учетной записи хостинга. Затем я синхронизировал его и настроил катализатор для использования небольшого моста cgi-fcgi. Это сработало. Красиво и быстро, потому что мост cgi - это всего лишь крошечный исполняемый файл. Каталитический процесс прекрасно сохранился в фоновом режиме.
Это в основном зависит от того, насколько сложен ваш код и как он скомпонован; если вы запустите его как CGI, perl будет компилировать ваш скрипт и модули при каждом вызове, и ему придется повторно подключаться к вашей базе данных для каждого запроса. Если ваш код достаточно сложен, это может занять несколько секунд на просмотр страницы, что может затруднить взаимодействие с пользователем.
Если ваша кодовая база и используемые модули невелики, проблем быть не должно.
Вы можете выполнить команду perl -c в своем коде, чтобы понять, как долго длится запуск Perl и время компиляции.
PHP должен перекомпилировать ваши скрипты при каждом вызове, если кеш кода операции не установлен. Соединения с базой данных могут быть общими, но некоторые веб-серверы (Apache в режиме prefork) плохо справляются с этим. Реальное ускорение PHP происходит за счет встраивания mod_php в серверный процесс.
Это зависит от того, как запущен PHP. PHP как CGI (обычно запускаемый хостингом), безусловно, медленнее, чем Perl как CGI или FastCGI.