Fragen zu FastCGI (Perl/CGI) - Perl-Community.de

[thread]13971[/thread]

Fragen zu FastCGI

Leser: 89

Question: Benutzt Ihr noch CGI
Check up to 5 answers
	CGI ist super
	Bin gezwungen CGI zu benutzen
	Benutze fcgi und/oder mod_perl
	Warte noch auf mod_perlite
	Ich will ein Bier
You have to log in to vote.
44 voter(s) so far

Articles: hide open all | hide show old branches

Teilbäume:
Zeitgemäß vs. Performance (22 Artikel) 2011-05-03 17:16
Fragen zu FastCGI (12 Artikel) 2010-03-20 15:52

+13 replies
bianca

2010-02-03 14:58

User since
2009-09-13
7016 Artikel
BenutzerIn

2010-02-03T13:47:53 sid burn
Du könntest aber FastCGI nehmen.

Das finde ich zunehmend interessanter, je öfter davon geschrieben wird.
Gibt es dazu irgendwo eine deutsche Summary zu den Features, Voraussetzungen etc.?
Danke

mod-edit pq: teilbaum ausgelagert
Last edited: 2010-03-07 02:20:29 +0100 (CET)
10 print "Hallo"
20 goto 10
- +3 replies
- GwenDragon
  
  2010-02-03 15:36
  
  User since
  2005-01-17
  14875 Artikel
  Admin1
  
  Was willst du denn genau über FastCGI wissen?
  
  Beispiele unterstützter Server:
  Apache mit mod_fcgi
  lighthttpd
  ISS
  nginx
  
  Hinweise zu Skripten:
  * Das Skript wird einmal geladen und nimmt dann die Anfragen in einer Schleife entgegen.
  * Skripte sollten nicht mit exit beendet werden.
  * Globale Variablen sind zu vermeiden
  
  //EDIT: Wenn du mehr wissen willst, ist es vielleicht sinnvoller einen eigenen Thread zu Fragen zu FastCGI aufzumachen.
  Last edited: 2010-02-03 15:37:34 +0100 (CET)
  die Drachin Gwen
  
  Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
  - +2 replies
  - bianca
    
    2010-02-03 15:41
    
    User since
    2009-09-13
    7016 Artikel
    BenutzerIn
    
    Danke Dir, hab auch schon http://de.wikipedia.org/wiki/FastCGI gelesen.
    Muss mal mit dem Provider sprechen.
    Dann mach ich ggf. einen eigenen Thread auf.
    Gibt es denn hier Teilnehmer, die damit aktiv/produktiv arbeiten?
    10 print "Hallo"
    20 goto 10
    - sid burn
      
      2010-02-03 15:45
      
      User since
      2006-03-29
      1520 Artikel
      BenutzerIn
      
      Direkt nicht, würde ich auch nicht machen. Ich nutze aber Catalyst und lasse es über FastCGI laufen.
      Ansonsten würde ich PSGI/Plack nutzen wie ich unten bereits erwähnte.
      Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
- +7 replies
- sid burn
  
  2010-02-03 15:43
  
  User since
  2006-03-29
  1520 Artikel
  BenutzerIn
  
  Hmm, mir ist nicht ganz klar was du genau darüber Wissen möchtest. FastCGI ist wie CGI ein Interface.
  Bei FastCGI startet deine Applikation selber aber als ein Daemon.
  Ein Webserver kommuniziert dann entweder über ein Unix Socket oder TCP Socket mit deiner Applikation.
  
  Anfragen werden also zu deiner laufenden Applikation gesendet, und dein FastCGI prozess gibt die Antwort zurück.
  
  Die Vorteile sind eben das es persistent ist. Daher eine Datenbankverbindung wird nur einmalig aufgebaut. Genauso werden alle Module nur einmalig beim start geladen. Das gilt generell eben für die ganze Applikation. Das macht es deutlich schneller. In der Regel auch Speicherschonender.
  
  Ansonsten ist FastCGI eben nur ein Interface, wenn du es nutzen möchtest musst du zum Beispiel spezielle Module wie FCGI nutzen.
  
  Besser ist aber du nutzt ein Web-Framework z.B. Catalyst. Diese abstrahieren die ausführung so das es eben auf mod_perl, FastCGI, CGI oder anderes läuft.
  
  Andere Frameworks bieten meist auch eine ähnliche Abstraktion. Ansonsten wenn du ein eigenes Framework schreibst, oder gar kein Framework nutzt dann solltest du wohl eher PSGI nutzen.
  
  PSGI selber ist wieder ein eigenes Interface das du nutzt. Wenn du dies aber nutzt kannst du die unterschiedlichen ausführmethoden wie CGI, FastCGI nutzt. PSGI vereinheitlich also den Zugriff auf/mit Webserver über eine einheitliche API. Ansonsten gibt es dann halt eben noch Plack das eine Implementierung von PSGI ist.
  
  Mehr Informationen zu PSGI/Plack gibt es hier: http://plackperl.org/
  Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
  - +6 replies
  - bianca
    
    2010-02-03 15:59
    
    User since
    2009-09-13
    7016 Artikel
    BenutzerIn
    
    Ist denn der generelle Performancegewinn maßgeblich und für den Benutzer spürbar, wenn man
    a) keine DB nutzt
    und
    b) lediglich CGI, strict, warnings und Fcntl beim Start lädt und den Rest nur dynamisch bei Bedarf per require?
    Also würde sich bei einer solchen Konzeption die Beschäftigung mit dem Thema generell lohnen Eurer Meinung nach?
    10 print "Hallo"
    20 goto 10
    - GwenDragon
      
      2010-02-03 16:29
      
      User since
      2005-01-17
      14875 Artikel
      Admin1
      
      Selbst require hat ja Ladezeit.
      
      Mach mal folgendes in deinem Skript.
      Füge zu Beginn zum Mini-Benchmark ein:
      
      Code (perl): (dl )
      
      1 2 3 4 5 6 7
      
      BEGIN { use vars qw( $t0 ); use Time::HiRes qw( gettimeofday tv_interval ); # Test der Geschwindigkeit der Ausgabe $t0 = [ gettimeofday ]; }
      
      und am Ende:
      
      Code (perl): (dl )
      
      1 2 3
      
      END { warn "Das Skript $0 brauchte " . (tv_interval( $t0 ) * 1000) . 'msec'; }
      
      Dann siehste, wie schnell das Skript im Ganzen ist.
      
      Schau dir mal an wie schnell das Perl-Blog MoveableType wird mit fastcgi. 10× so schnell bei den Requests.
      
      //EDIT: Weiteres zu Performanceüberlegungen (en.) bei FastCGI.
      
      Ja, eine Umstellung würde sich lohnen.
      Last edited: 2010-02-03 16:32:26 +0100 (CET)
      die Drachin Gwen
      
      Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
    - sid burn
      
      2010-02-03 16:46
      
      User since
      2006-03-29
      1520 Artikel
      BenutzerIn
      
      Deine Fragen lassen sich so nicht einfach mit einem ja/nein beantworten.
      
      Quote
      Ist denn der generelle Performancegewinn maßgeblich und für den Benutzer spürbar, wenn man
      a) keine DB nutzt
      
      Als erstes im groben würde wohl die Performane eher drunter leiden. Persistenz von Daten war schon immer ein Thema und irgendwie musst du Daten auf die Festplatte schreiben und wieder auslesen.
      
      Datenbanken sind ja gerade dafür da das zu Abstrahieren. Natürlich kann es in einem absolut kleinen minifall sogar performanter sein einfach eine kleine JSON datei zu nehmen, diese einzulesen und zu präsentieren als eine Datenbank.
      
      Aber spätestens wenn du viele parallele zugriffe hast rennst du in Probleme mit locking. Und auch die Datei jedesmal neu von der Festplatte zu lesen ist nicht gerade intelligent. Datenbanken cachen halt sachen im Speicher und diese laufen ja ebenfalls Persistent.
      
      Bei jedem Problem das nicht trivial und schon über ein "Hello, World" hinaus geht würde ich also schon eine DB nehmen. Bei allem anderen fängst du an praktisch eine Datenbank von vorne zu Programmieren.
      
      Quote
      b) lediglich CGI, strict, warnings und Fcntl beim Start lädt und den Rest nur dynamisch bei Bedarf per require?
      
      Warum sollte das schneller als eine Persistenz sein? Bei der Persistenz lädst du ein Modul einmalig. Mit require lädst du es immer wieder neu wenn dein Code nicht persistent ist. Und ob "require" oder "use" macht auch kein unterschied. Auser du hast zig verschiedene Programmfade so das bei einem mal mehr und beim anderen pfad mal weniger Module geladen werden. Trotzdem würde eine persistenz alle module nur einmalig für alle folgendenen Anfragen etwas laden.
      
      Quote
      Also würde sich bei einer solchen Konzeption die Beschäftigung mit dem Thema generell lohnen Eurer Meinung nach?
      
      Welches Thema genau? das was du meinst mit strict, warnings und require zu laden? Nein lohnt sich nicht.
      Generell Persistente Umgebungen? Ja defenitiv.
      
      Ich würde mich aber nicht wie bereits gesagt speziell auf FastCGI einschießen sondern ein Framework wie Catalyst oder eine Abstraktion wie PSGI/Plack nutzen.
      Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
    - +2 replies
    - pq
      
      2010-02-03 17:09
      
      User since
      2003-08-04
      12209 Artikel
      Admin1
      
      zur frage, ob es für den user spürbar ist:
      das kann man pauschal gar nicht beantworten. es kommt darauf an, wie schnell der server ist und wie lange ein request mit CGI dauert.
      dauert er z.b. nur eine sekunde, wird der user kaum einen unterschied spüren. je mehr zugriffe du aber hast, desto mehr last ist auf dem server und desto öfter überschneiden sich die requests, wodurch es dann insgesamt langsamer wird.
      der gewinn ist eher, dass es skaliert.
      
      am beispiel von battie kannst du mal sehen, wie gross der unterschied ist:
      CGI: http://battie.perl-community.de/cgi/battie.cgi/poa...
      mod_perl: http://battie.perl-community.de/bat/poard/start
      (mod_perl und FastCGI sind da ungefähr vergleichbar)
      
      der unterschied ist hier sehr deutlich, aber battie lädt auch wirklich *sehr* viele module und macht sehr viel vor und nach dem eigentlichen request, was bei der mod_perl-variante gespart wird.
      
      die kunst eines entwicklers ist eben, von fall zu fall entscheiden zu können, was lohnt.
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
      lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
      - bianca
        
        2010-02-03 17:57
        
        User since
        2009-09-13
        7016 Artikel
        BenutzerIn
        
        2010-02-03T16:09:25 pq
        am beispiel von battie kannst du mal sehen, wie gross der unterschied ist:
        CGI: http://battie.perl-community.de/cgi/battie.cgi/poa...
        mod_perl: http://battie.perl-community.de/bat/poard/start
        (mod_perl und FastCGI sind da ungefähr vergleichbar)
        
        Ja, das ist tatsächlich sehr spürbar. Krass.
        Danke für die Info.
        Muss mal überlegen.
        10 print "Hallo"
        20 goto 10
    - GwenDragon
      
      2010-02-04 14:32
      
      User since
      2005-01-17
      14875 Artikel
      Admin1
      
      Ob sich das für lohnt, hängt davon ab: wieviele Besucher auf dem Server sind, ob das ein VServer oder eigener Rootserver ist (wegen der Resourcen von RAM und Disk sowie der gesamten Auslastung durch viele Kunden auf dem Server), wie lange das Laden der Module im Programm dauert.
      
      Es ist möglich, mit Devel-NYTProf Skripte zu analysieren und dann ist ersichtlich wieviel Zeit wofür drauf geht. Die Flaschenhälse im Programm, in den Modulen sind dann einfacher zu finden. nytprof gibt auch HTML-Seiten aus, das dann übersichtliche Informationen bietet.
      die Drachin Gwen
      
      Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
- +2 replies
- roooot
  
  2010-03-20 15:42
  
  User since
  2008-03-03
  276 Artikel
  BenutzerIn
  
  Mal eine weitere Frage zu der Thematik.
  Lassen sich CGI Scripte in FastCGI Scripte umformen?
  Habe mich nur mal kurz eingelesen, da mein Hoster das zur Zeit eh nicht unterstützt, aber besteht der Unterschied im Script nur in dem statischen -- einmal ausgeführten -- Teil mit nachfolgender Schleife? Sprich es lassen sich altmodische CGIs leicht in FastCGI Scripte umformen?
  Viele Grüße :)
  - renee
    
    2010-03-20 15:52
    
    User since
    2003-08-04
    14371 Artikel
    ModeratorIn
    
    Wenn man sauber programmiert hat, ist die Umstellung in wenigen Minuten erledigt...
    
    Man sollte halt keine globalen Variablen haben, sondern Sachen lieber als Parameter an Funktionen übergeben.
    
    Dann den normalen "Skript"-Teil in eine Subroutine, "FCGI" einbinden und die while-Schleife aus der Synopsis von FCGI in das CGI-Skript kopieren - fertig.
    OTRS-Erweiterungen (http://feature-addons.de/)
    Frankfurt Perlmongers (http://frankfurt.pm/)
    --
    
    Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
    Perl-Entwicklung: http://perl-services.de/

View all threads created 2009-09-02 17:10.