Quando dovrei usare Perl CGI invece di PHP (o viceversa)?

StackOverflow https://stackoverflow.com/questions/824730

  •  05-07-2019
  •  | 
  •  
È stato utile?

Soluzione

Il carattere "obsoleto" di CGI è davvero solo un fattore se si stanno realizzando siti grandi e complessi con molte visualizzazioni di pagina.

Molte persone spingono l'idea che la CGI sia obsoleta, in realtà non capiscono cosa sia la CGI. C'è un malinteso diffuso sul fatto che la CGI sia una tecnologia intrinsecamente basata sul Perl. Molte persone attaccano la CGI come un modo per completare gli attacchi di culto su Perl a supporto di qualunque lingua supportino. Se vuoi essere un vero tecnologo, devi capire le questioni fondamentali e fare una scelta in base ai fatti della situazione.

CGI è un'interfaccia con un server web che ti permette di scrivere pagine interattive in qualsiasi lingua-- persino 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 che una VM, un interprete o un compilatore vengano caricati ogni volta che viene eseguito, questo tempo di avvio sarà richiesto ogni volta che accedi alla tua pagina.

Gli acceleratori CGI come FastCGI, mod_php, mod_perl e così via, mantengono sempre in memoria un interprete / VM, possono caricare le librerie e persino memorizzare il codice byte degli script per ridurre l'overhead di avvio degli script.

Se stai realizzando un sito semplice, personale o per hobby, CGI andrà bene. Anche PHP.

Se il tuo sito deve crescere per richiedere una tecnologia più veloce, puoi passare a mod_perl, FastCGI o altre tecnologie di accelerazione CGI.

La lingua che usi dovrebbe essere determinata dagli strumenti che fornisce e da come si adattano alle tue esigenze.

  1. Crea un elenco delle funzionalità di cui hai bisogno.
  2. Crea un elenco di interruttori di offerte.
  3. Ora controlla ciascuno dei tuoi possibili set di strumenti rispetto a questi due elenchi.
  4. Qual è il migliore? Provalo.
  5. Fa schifo? Cancellalo dall'elenco e torna al passaggio 4.

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

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

FastCGI è un acceleratore CGI puro.

Aggiornamento 2: PHP e CGI non si escludono a vicenda. PHP può essere installato come CGI . PHP viene spesso utilizzato con FastCGI.

Altri suggerimenti

Questo è un problema abbastanza soggettivo per decidere cosa usare per un hobby. Ho deciso di imparare il Perl come hobby dopo aver esaminato PHP e non aver apprezzato il fatto che non potevo leggere la maggior parte del PHP là fuori ed essere scoraggiato dall'elenco delle funzioni integrate.

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

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

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

Quindi, la mia risposta è, scegli un piccolo progetto, tutto farà e implementalo usando Perl e i moduli CPAN appropriati e vedi se ti piace.

Sia che usi PHP o Perl è discutibile dal punto di vista del ridimensionamento, tanto quanto la differenza tra una webapp scritta in PHP e C è controversa. Se la differenza fosse davvero importante, scriveremmo tutti C o assembly.

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

Ci sono due ragioni principali per cui non importa, dal punto di vista del ridimensionamento, quale lingua scegli:

  1. Usa un proxy inverso nella cache come Squid. Scaricando la maggior parte del carico di lavoro di apache, puoi ridurre drasticamente il carico di invocazione CGI.
  2. Il ridimensionamento del livello Web è semplice. È difficile ridimensionare il livello del database. È 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 per sviluppare il CGI, fallo. Avrai bisogno di un numero doppio di web head, ma uno dei due:
    1. Sei nella parte inferiore del 90% del Web e in ogni caso hai davvero bisogno di un solo server web.
    2. Sei tra i primi 10% del Web e hai bisogno di più server web, ma hai abbastanza traffico per giustificare il costo aggiuntivo.

Scegli la lingua che tu e il tuo team potete sviluppare in modo più efficiente.

Ecco un semplice "ciao mondo" esempio che funziona in CGI usando Squatting microframework 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 inseriscilo nel tuo cestino.

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

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

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

HTH

Colin

Se usi l'hosting, in molti casi PHP verrebbe eseguito anche come CGI. Se non si desidera eseguire FastCGI o mod_perl, è possibile utilizzare CGI :: Framework applicazione . CGI :: L'applicazione verrà eseguita anche con FastCGI o mod_perl, ma diversamente da Catalyst verrà eseguita anche come CGI. Catalyst e CGI :: Application possono anche essere eseguiti con i propri server Web.

Sia PHP che Perl hanno i loro momenti, ma questo è veramente soggettivo. Perl dispone di enormi framework disponibili su CPAN che possono farlo funzionare anche o meglio di PHP, anche in un ambiente puramente CGI. Allo stesso tempo, PHP ha un vasto seguito e tantissime funzionalità predefinite per semplificare la programmazione del sito Web. La scelta, per me, si riduce alle preferenze personali. Personalmente preferisco usare Perl piuttosto che scherzare cercando di trovare tutti i modi funzionali per fare le cose in PHP. Buona fortuna!

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>
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top