2009-05-05 11 views
12

Per scopi di hobby, ho uno spazio condiviso su un server di hosting che fornisce, come molti di loro, sia PHP che Perl CGI. Ho letto su diversi punti che gli script CGI sono obsoleti ora, penso principalmente per problemi di prestazioni (come Is PHP or vanilla Perl CGI faster?).Quando dovrei usare Perl CGI al posto di PHP (o viceversa)?

Ma da quando ho appena iniziato a studiare Perl, non vorrei perdere tempo a implementare soluzioni in PHP che sono molto più semplici (o possibili solo) in Perl.

Inoltre ci sono i problemi di boilerplate, sono a conoscenza di CPAN (cioè dell'esistenza, non ancora del contenuto), ma non ho familiarità con le librerie PHP (anche se non ho dubbi che esistano). Non sono disposto a scrivere una procedura di accesso o una gestione utenti di base da zero per la 10a/10a volta.

Non ho il lusso, a questo punto, di sprecare un sacco di tempo nella ricerca di progetti per hobby, quindi ho pensato, chiediamo agli esperti un vantaggio.

+2

Invece di semplice CGI, dai un'occhiata a Catalyst. http://catalystframework.org –

+1

@Brad Gilbert - Stai confondendo CGI.pm e CGI l'interfaccia. Catalyst può essere eseguito come CGI (l'overhead di avvio è un po 'ripido, ma potrebbe essere accettabile). – daotoad

+0

La domanda è se ti forniscono un'interfaccia CGI per il webserver, CGI.pm o entrambi. La coincidenza di nominare significa che non possiamo dire - lo sai? – ijw

risposta

28

L'"obsoleto" -nessità di CGI è davvero solo un fattore se si stanno facendo siti grandi e complessi con molte visualizzazioni di pagina.

Molte persone spingono l'idea che CGI sia obsoleto in realtà non capiscono cosa sia CGI. Vi è un equivoco diffuso sul fatto che la CGI sia una tecnologia intrinsecamente basata sul Perl. Molte persone attaccano la CGI come un modo per riempire gli attacchi settici su Perl a sostegno di qualsiasi lingua supportino. Se vuoi essere un vero tecnico, devi capire le questioni fondamentali e fare una scelta basata sui fatti della situazione.

CGI è un'interfaccia con un server Web che consente di scrivere pagine interattive in qualsiasi lingua - even befunge. Quando un server riceve una richiesta per una pagina controllata da uno script CGI, il server esegue lo script e restituisce i risultati al richiedente.

Se il tuo linguaggio di programmazione richiede una VM, un interprete o un compilatore da caricare ogni volta che viene eseguito, allora questo tempo di avvio sarà richiesto ogni volta che si accede alla pagina.

Gli acceleratori CGI come FastCGI, mod_php, mod_perl e così via, mantengono un interprete/VM in memoria in ogni momento, possono mantenere le librerie caricate e persino cache bytecode dagli script per ridurre il sovraccarico di avvio dello script.

Se stai facendo un sito semplice, personale o per hobby, CGI andrà bene. Così sarà PHP.

Se il tuo sito necessita di una tecnologia più veloce, puoi passare a mod_perl, FastCGI o ad altre tecnologie di accelerazione CGI.

La lingua utilizzata deve essere determinata dagli strumenti che fornisce e dal modo in cui si adattano alle esigenze.

  1. Fare un elenco delle funzionalità necessarie.
  2. Fai una lista di demolitori di offerte.
  3. Ora controlla ciascuno dei tuoi set di strumenti possibili rispetto a questi due elenchi.
  4. Quale ne esce il migliore? Provalo.
  5. Fa schifo? Cancellalo dalla lista e torna al passaggio 4.

Inoltre, consiglio di non utilizzare befunge. Solo perché è possibile, non significa che dovresti usarlo.


Aggiornamento: Come mpeters sottolinea, mod_perl, mod_php, mod_ruby, et alia sono molto più di semplici acceleratori CGI; forniscono accesso all'API Apache. Agiscono come acceleratori CGI, ma possono fare molto, molto, molto altro.

FastCGI è un acceleratore CGI puro.

Aggiornamento 2: PHP e CGI non si escludono a vicenda. PHP can be installed as a CGI. PHP viene spesso utilizzato con FastCGI.

+3

Sebbene la maggior parte di ciò sia corretta, mod_perl non è solo un acceleratore CGI. In effetti, è una specie di effetto collaterale di darti la possibilità di controllare ogni bit del ciclo di richiesta di Apache in Perl. – mpeters

+2

Amen. Soprattutto il bit "CGI is language-agnostic" - la prima libreria CGI che abbia mai scritto era in realtà in C come un concerto di consulenti (che era tornato ai tempi del college quando ero molto bravo con C ma in qualche modo sono riuscito a non averne mai sentito parlare Perl :) – DVK

2

Uso sia il Perl che il PHP per i siti Web - per ragioni storiche, principalmente Perl al lavoro e PHP a casa; Non penso ci sia molto da scegliere tra loro.

Se le pagine sono per lo più fisse in HTML con solo una piccola quantità di calcolo, PHP è un po 'più semplice, perché è incorporato in HTML comunque.

Trovo PHP un linguaggio più disciplinato, e quindi a volte più limitante, di Perl. PEAR è molto simile a CPAN - non così grande, penso, ma poi CPAN è così grande che ha un sacco di scorie.

HTH

Colin

+4

L'incorporamento di codice HTML nel tuo codice è uno stile pessimo. –

+1

È possibile incorporare il codice Perl in HTML con Mason o Template-Toolkit, non che io lo consiglierei. –

8

questo è un problema abbastanza soggettivo per decidere cosa usare per un hobby. Ho deciso di imparare Perl come un hobby dopo aver guardato in PHP e non mi piace il fatto che non potessi leggere la maggior parte del PHP là fuori e di essere scoraggiato dall'elenco delle funzioni integrate.

Le prime cose che ho fatto sono stati script CGI per moduli di contatto e un generatore di album di foto. Ero su un piano hosting condiviso di cheapo e non ho riscontrato problemi di prestazioni, quindi il problema di prestazioni non è mai entrato in gioco.

Invece, l'esistenza di comp.lang.perl.misc e CPAN ha assicurato che non ho mai riconsiderato la mia decisione di non approfondire PHP.

Nel frattempo, ho realizzato che la maggior parte del contenuto dei miei siti Web è statico una volta generato, quindi ora scrivo gli script Perl per generare il contenuto offline.

Quindi, la mia risposta è, scegliere un piccolo progetto, qualsiasi cosa verrà eseguita e implementarla utilizzando Perl e moduli CPAN appropriati e vedere se ti piace.

1

Sia PHP che Perl hanno i loro momenti, ma questo è veramente soggettivo. Perl dispone di enormi framework disponibili su CPAN che possono farlo funzionare bene, o meglio, di PHP, anche in un ambiente puramente CGI. Allo stesso tempo, PHP ha un ampio seguito e un sacco di funzionalità out-of-the-box per semplificare la programmazione dei siti web. La scelta, per me, si riduce alle preferenze personali. Personalmente preferisco usare Perl piuttosto che cercare di trovare tutti i modi funzionali per fare cose in PHP. Buona fortuna!

+4

Perl potrebbe avere un seguito molto più ampio di PHP. PHP è utile solo per scrivere siti Web, Perl può essere utile in quasi tutte le aree della programmazione. –

1

Prova Catalyst con 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"> 
     &copy; [% copyright %] 
     </div> 
    </div> 
    </body> 
</html> 
+2

Non consiglierei Catalyst con un'interfaccia CGI per il server web, ma è una buona idea usare mod_perl o FastCGI. – ijw

+1

err, questo codice non fa quello che dice che fa. Forse vuoi dire dalla shell: script/vista myapp_create Web TT; Quindi aggiungere a Controller :: Root: sottochiavi: Path ('/ hello'): Args (0) { my ($ self, $ c) = @_; } e salva hello.tt nella directory principale. Anche mentre lavora in CGI, il successo delle prestazioni di catalyst è in fase di compilazione, quindi per tutti gli scopi pratici non userete mai CGI per eseguire un sito Catalyst. – singingfish

+0

Questa è solo una rappresentazione dello stile di un programma Catalyst, non un vero esempio di lavoro. –

2

Se si usa il hosting, in molti casi PHP sarebbe essere eseguito come CGI troppo. Se non vuoi eseguire FastCGI o mod_perl, puoi utilizzare CGI::Application framework. CGI :: L'applicazione verrà eseguita anche con FastCGI o mod_perl, ma a differenza di Catalyst verrà eseguito anche come CGI.Sia Catalyst che CGI :: Application possono anche essere eseguiti con i propri server web.

+0

Catalyst può anche essere eseguito come CGI, è solo molto lento. –

3

Sia che si utilizzi PHP o Perl è discutibile da una prospettiva di ridimensionamento molto nel modo in cui la differenza tra una webapp scritta in PHP e C è discutibile. Se la differenza fosse davvero importante, scriveremmo C o assembly.

PHP è lento, ma ciò non impedisce a Wikipedia, Facebook e Yahoo di utilizzarlo estensivamente.

Ci sono due motivi principali non importa, dal punto di vista di scala, che lingua scelta:

  1. utilizzare un proxy caching inverso come Squid. Scaricando la maggior parte del carico di lavoro di Apache, è possibile ridurre drasticamente il carico di chiamata CGI.
  2. Scalare il livello Web è facile. Sta scalando il tuo livello di database che è difficile. È sempre possibile aggiungere un altro server Web alla farm. Se puoi servire 1000 richieste al secondo con mod_php e 500 richieste al secondo con un CGI, se è più economico e veloce sviluppare lo CGI, fallo. Avrai bisogno di due volte più webhead, ma:
    1. Sei nel 90% del Web in basso e, in ogni caso, hai solo bisogno di un server web.
    2. Sei nella top 10% del Web e hai bisogno di più server web, ma hai abbastanza traffico per giustificare il costo aggiuntivo.

Scegli la lingua che voi e la vostra squadra può sviluppare in modo più efficiente.

3

Ecco un semplice "ciao mondo" esempio che corre sotto CGI utilizzando il microframework Squatting web:

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); 

Salva come "myapp.cgi" e posto nella vostra cgi-bin.

Problemi correlati