Когда я должен использовать Perl CGI вместо PHP (или наоборот)?
Для целей хобби у меня есть общее пространство на сервере хостинга, который предоставляет, как и многие из них, как PHP, так и Perl CGI. Я читал в нескольких местах, что скрипты CGI устарели сейчас, я думаю, что в основном для проблем с производительностью (например, быстрее ли PHP или ванильный Perl CGI?).
Но так как я только начал изучать Perl, я бы не хотел тратить время на внедрение решений на PHP, которые проще (или только возможно) в Perl.
Также есть проблемы с шаблоном, я знаю CPAN (это существование, еще не контент), но не знакомы с библиотеками PHP (хотя я не сомневаюсь, что они существуют). Я не готов писать процедуру входа в систему или базовое администрирование пользователя с нуля в течение 10-10 раз.
Я не роскошь на данный момент тратить много времени на исследования для проектов хобби, так что я подумал, позвольте спросить экспертов за голову.
Ответы
Ответ 1
"Устаревшая" -ность CGI действительно является лишь фактором, если вы делаете большие сложные сайты с большим количеством просмотров страниц.
Многие люди выдвигают идею о том, что CGI устарел, на самом деле не понимают, что такое CGI. Существует распространенное заблуждение о том, что CGI - это технология, основанная на Perl. Многие люди атакуют CGI как способ отбросить культовые атаки на Perl в поддержку любого языка, который они поддерживают. Если вы хотите быть настоящим технологом, вам нужно понять фундаментальные проблемы и сделать выбор, основанный на фактах ситуации.
CGI - это интерфейс с веб-сервером, который позволяет вам писать интерактивные страницы на любом языке - даже befunge. Когда сервер получает запрос на страницу, управляемую CGI script, сервер запускает script и возвращает результаты реквестеру.
Если ваш язык программирования требует, чтобы каждый раз, когда он выполнял загрузку виртуальной машины, интерпретатора или компилятора, это время запуска было необходимо при каждом обращении к вашей странице.
Ускорители CGI, такие как FastCGI, mod_php, mod_perl и т.д., всегда сохраняют в памяти интерпретатор/виртуальную память, могут загружать библиотеки и даже кэшировать байт-код из сценариев, чтобы уменьшить накладные расходы script.
Если вы делаете простой, персональный или хобби-сайт, CGI будет в порядке. Так будет PHP.
Если ваш сайт должен расти быстрее, вы можете перейти на mod_perl, FastCGI или другие технологии ускорения CGI.
Какой язык вы используете, должны определяться инструментами, которые он предоставляет, и как они соответствуют вашим потребностям.
- Составьте список необходимых вам возможностей.
- Составьте список выключателей.
- Теперь проверьте каждый из ваших возможных наборов инструментов против этих двух списков.
- Какой из лучших выходит? Проверьте его.
- Это сосать? Перечеркните его из списка и вернитесь к шагу 4.
Кроме того, я рекомендую использовать befunge. Просто потому, что это возможно, это не значит, что вы должны его использовать.
Обновление: Как отмечают mpeters, mod_perl, mod_php, mod_ruby и др. намного больше, чем просто ускорители CGI; они обеспечивают доступ к API Apache. Они действуют как ускорители CGI, но могут делать многое, многое другое.
FastCGI - это чистый ускоритель CGI.
Обновление 2: PHP и CGI не являются взаимоисключающими. PHP может быть установлен как CGI. PHP часто используется с FastCGI.
Ответ 2
Это довольно субъективная проблема для решения, что использовать для хобби. Я решил изучить Perl как хобби после изучения PHP, и мне не понравилось то, что я не мог прочитать большую часть PHP там и был лишен списка встроенных функций.
Первые несколько вещей, которые я сделал, это скрипты CGI для контактных форм и генератор фотоальбомов. Я был на дешевом общедоступном хостинговом плане, и у меня не было проблем с производительностью, поэтому проблема с производительностью никогда не входила в игру.
Вместо этого существование comp.lang.perl.misc и CPAN гарантировало, что я никогда не пересматривал свое решение не вникать в PHP.
В то же время я понял, что большая часть контента на моих веб-сайтах статична после создания, поэтому теперь я пишу сценарии Perl для создания контента в автономном режиме.
Итак, мой ответ: выберите небольшой проект, что-нибудь сделаете и реализуйте его с помощью Perl и соответствующих модулей CPAN и посмотрите, нравится ли вам это.
Ответ 3
Если вы используете PHP или Perl является спорным с точки зрения масштабирования гораздо таким образом, что разница между веб-приложение написано в PHP и C является спорным. Если различие действительно имело значение, мы все будем писать C или сборку.
PHP медленный, но это не останавливает использование Wikipedia, Facebook и Yahoo.
Есть две основные причины: неважно, с точки зрения масштабирования, какой язык вы выберете:
- Используйте обратный прокси-сервер кэширования, например Squid. Разгружая большую часть рабочей нагрузки apache, вы можете резко сократить нагрузку на вызов CGI.
- Масштабирование вашего веб-уровня легко. Это сильно масштабирует ваш уровень базы данных. Вы всегда можете добавить еще один веб-сервер в ферму. Если вы можете подавать 1000 запросов в секунду с помощью mod_php и 500 запросов в секунду с помощью CGI, если вам дешевле и быстрее вы разрабатываете CGI, сделайте это. Вам понадобится в два раза больше веб-головок, но также:
- Вы находитесь в нижней 90% сети, и в любом случае вам действительно нужен один веб-сервер.
- Вы находитесь в топ-10% Интернета и нуждаетесь в нескольких веб-серверах, но у вас достаточно трафика, чтобы оправдать дополнительные затраты.
Выберите язык, который вы и ваша команда можете разработать наиболее эффективно.
Ответ 4
Вот простой пример "привет мир", который работает под CGI, используя Squatting веб-микрокадр:
use strict;
use warnings;
{
package MyApp;
use base 'Squatting';
use base 'Squatting::On::CGI';
}
{
package MyApp::Controllers;
use Squatting ':controllers';
our @C = (
C(
Index => [ '/' ],
get => sub {
my ( $self ) = @_;
my $v = $self->v;
$v->{say} = 'hello world!';
$self->render( 'hello' );
},
),
);
}
{
package MyApp::Views;
use Squatting ':views';
use HTML::AsSubs;
our @V = (
V( 'html',
layout => sub {
my ( $self, $v, @yield ) = @_;
html (
head ( title( 'My CGI App' ) ),
body ( @yield ),
)->as_HTML;
},
hello => sub {
my ( $self, $v ) = @_;
p ( $v->{say} );
},
),
);
}
use CGI;
my $q = CGI->new;
MyApp->init;
MyApp->relocate('/cgi-bin/myapp.cgi');
MyApp->cgi($q);
Сохраните как "myapp.cgi" и поместите в свой cgi-bin.
Ответ 5
Я использую как Perl, так и PHP для сайтов - по историческим причинам, главным образом Perl на работе и PHP дома; Я не думаю, что есть много выбора между ними.
Если ваши страницы в основном фиксированы HTML с небольшим количеством вычислений, PHP немного проще, поскольку он все равно встроен в HTML.
Я считаю PHP более дисциплинированным и, следовательно, иногда более ограниченным, языком, чем Perl. PEAR очень похож на CPAN - я думаю, не такой большой, но тогда CPAN настолько велик, что в нем много шлаков.
НТН
Колин
Ответ 6
Если вы используете хостинг, во многих случаях PHP будет запущен как CGI. Если вы не хотите запускать FastCGI или mod_perl, вы можете использовать CGI:: Application framework. CGI:: Приложение будет работать с FastCGI или mod_perl, но в отличие от Catalyst будет работать как CGI. Оба Catalyst и CGI:: Application также могут запускаться со своими собственными веб-серверами.
Ответ 7
И PHP, и Perl имеют свои моменты, но это действительно субъективно. Perl имеет массивные рамки, доступные на CPAN, которые могут заставить его работать, или лучше, чем PHP, даже в чисто CGI-среде. В то же время PHP имеет большое количество и тонну функций, которые делают сайт простым.
Выбор, для меня, сводится к личным предпочтениям. Я лично предпочитаю использовать Perl, а не гадать, пытаясь найти все функциональные способы делать что-то в PHP.
Удачи!
Ответ 8
Попробуйте Catalyst с Template Toolkit.
sub hello :Path('/hello') :Args(0) {
my ( $self, $c ) = @_;
# Hello World
$c->response->body( $c->welcome_message );
}
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN">
<html>
<head>
<title>[% title %]</title>
</head>
<body>
<div id="header">
<a href="/index.html" class="logo" alt="Home Page"></a>
<h1 class="headline">[% title %]</h1>
</div>
[% content %]
<div id="footer">
<div id="copyright">
© [% copyright %]
</div>
</div>
</body>
</html>