Erfahrung mit SpeedyCGI (Webframeworks, Sonstige Fragen zur Webprogrammierung mit Perl)

[thread]16424[/thread]

Erfahrung mit SpeedyCGI

Tags: perl5 SpeedyCGI Ähnliche Threads

Leser: 31

Articles: hide open all | hide show old branches

+20 replies
marky

2011-06-16 18:26

User since
2003-08-15
215 Artikel
BenutzerIn

Hallo,

ich habe gerade mit nur sehr wenigen Handgriffen ein grösseres System unter SpeedyCGI zum Laufen bekommen, die 2-3 globalen Vars konnte ich einfach eine start-Sub packen und per local definieren und das ging erstaunlicherweise :-) der Performancezuwachs ist enorm. Und die Anpassungen für ein "normales" CGI extrem gering.

Dazu habe ich jetzt 2 Frage

- Hat jemand von euch erfahrung mit dem Modul im Produktiveinsatz
- Kann man FCGI gleich nutzen was das definieren der globalen Vars als Local in einer start-routine angeht

Gruss M. Wolf
Mfg
Markus - http://www.perlunity.de -
- Gast senfomat
  
  2011-07-16 13:00
  
  Hallo,
  
  ich habe eine produktive Text-Suchengine und diverse Mapping-Dienste seit ein paar Jahren unter SpeedyCGI am laufen. Demnächst will ich eine Forensoftware damit aufpeppen, damit die nicht immer alles aus der DB holen muss sondern mit Speedy bestimmte Bereiche cachen und direkt ausliefern kann.
  
  Ich bin echt beeindruckt mit wie wenig Aufwand man da die Performance rausholen kann. Vor allem das besagte Caching von mit "our"-definierten Variablen zwischen den Requests bringt enorme Vorteile. Es läuft wie gesagt seit Jahren stabil und ohne jede Probleme.
  
  Dass SpeedyCGI seit 2003 nicht mehr angefasst wurde, macht mich allerdings etwas nachdenklich. Wobei ich auch keine Probleme damit habe, also vermute ich mal dass es fast Bugfrei ist ;-)
  
  Aber auch nur fast bugfrei, denn ich habe festgestellt, dass die Speedy-Performance teilweise einbricht, wenn man mit $_ als Variablen arbeitet, z.B. in foreach-Loops. Nachdem ich die Variablen mit "my $blah" richtig definiert habe, war auch Speedy wieder rasend schnell.
  
  Zu Fast-CGI kann ich nichts sagen, das habe ich nicht im Einsatz.
  
  Gruß,
  senfo
  Last edited: 2011-07-16 13:03:09 +0200 (CEST)
- +18 replies
- roooot
  
  2011-07-18 23:41
  
  User since
  2008-03-03
  276 Artikel
  BenutzerIn
  
  Ich habe es eine Zeitlang auf meinen Server verwendet. Lief in Kombination mit lighttpd und Perl 5.10 unter Debian Lenny. Das ganze in einem chroot.
  
  Nach dem Wechsel auf Squeeze wurde es dann unmöglich es zu kompilieren und ich bin auf FastCGI umgesprungen. Mein Framework ist entsprechend zu konfigurieren, sodass neben Konfiguration in der lighttpd.conf nur eine CGI::Fast Schleife nötig ist, bzw nach implementierung des FCGI Handlers nur ein config Wert geändert werden muss. Catalyst oder Mojo bieten dir das selbe an.
  
  Die Performance ist nochmal besser als bei SpeedyCGI. Allerdings schirmt FCGI (worauf CGI::Fast aufbaut) den %ENV für jeden Aufruf ab, sprich du kannst das nicht benutzen um Sessionparameter vorzuhalten. SpeedyCGI ist hier meiner Meinung nach zu nachgiebig. Sicherheitstechnisch ist es ein unding, dass Variablen zwischen den Requests weiter existieren. Entweder man ist zu faul im Ram zu cachen oder man weiß es nicht besser. Nein, sowas macht man einfach nicht.
  
  Fazit: SpeedyCGI mag bequem sein, allerdings ist dann doch schon etliche Jahre (ich glaube 7) unmaintained. Perl 5.8 war damals aktuell, jetzt sind wir bei 5.14.1. Schmeiß es weg, benutzte FCGI oder PLACK (wobei ich letzteres nicht zum Laufen bekommen habe und FastCGI 1a funktioniert).
  Im Endeffekt benutzen ja sowieso beide Unix Sockets...
  Last edited: 2011-07-18 23:45:48 +0200 (CEST)
  Viele Grüße :)
  - +17 replies
  - marky
    
    2011-07-19 21:05
    
    User since
    2003-08-15
    215 Artikel
    BenutzerIn
    
    Hallo, danke für die Info.
    
    Ich konnte speedy aber ganz normal per apt unter Squeeze installieren. Aber in der Tat war mir nie wohl bei der Sache.
    
    FCGI hat bei meinen Versuchen damals einfach nicht geklappt, aber jetzt hat es direkt geklappt, manchmal muss man die Sachen einfach liegen lassen. Die Last und der Speicherverbrauch ist geringer - ich teste mit jmeter und vdsl -> 25mbit damit schaffe ich so 150 gleichzeitige Abrufe und kann auf einem einfach 30 EUR account trotzdem noch sehr flüssig surfen. Und es läuft das gleiche Script wie unter Speedy nur mit der Schleife um das start-Unterprogramm.
    
    Leider gibt es nicht so wirkliche viele Infos zu Technik. Ich gehe mal davon aus, dass globale Vars auch hier global sind.
    
    Die globalen Vars des Script hatte ich ja schon per local im start-Sub lokalisiert, das klappt gleich wie bei Speedy. Ich denke mal auch require wird nur einmal ausgeführt, dort habe ich dann "do" eingesetzt, wo das bei jedem Aufruf nötig ist.
    
    Was muss man denn noch beachten, so einfach kann das doch nicht sein. Ich kann mich noch an mod_perl Zeiten erinnern, da war das wirklich ein mega-akt und deguggen sehr schwierig.
    
    Ah eine Frage habe ich noch ich habe 2 "exits" wie kann ich das unter FCGI machen, dh. das Script an der Stelle verlassen, ohne den Prozess zu beenden?
    
    Gruss Marky und nochmals danke für den kleinen "Arschtritt" :-)
    Mfg
    Markus - http://www.perlunity.de -
    - +8 replies
    - kristian
      
      2011-07-19 22:44
      
      User since
      2005-04-14
      684 Artikel
      BenutzerIn
      
      Hallo
      
      2011-07-19T19:05:47 marky
      Ah eine Frage habe ich noch ich habe 2 "exits" wie kann ich das unter FCGI machen, dh. das Script an der Stelle verlassen, ohne den Prozess zu beenden?
      
      Das kommt drauf an, wo die exit stehen, entweder suchst du return oder next.
      Ich denke es sollte return 1 sein, wenn dein "Hauptprogramm" so aussieht:
      
      Code (perl): (dl )
      
      1 2 3 4 5 6 7 8
      
      _init(); while ( $query = new CGI::Fast ) { last unless ( _dispatch() ); last if ( -M $ENV{'SCRIPT_FILENAME'} < 0 ); $run_count++; last if ( $run_count > $max_runs ); } _exit();
      
      und das "exit" irgendwo in _dispatch() steht.
      
      Gruß
      Kristian
      - +7 replies
      - marky
        
        2011-07-20 09:29
        
        User since
        2003-08-15
        215 Artikel
        BenutzerIn
        
        Hallo,
        
        da geht so leider so nicht, das ist rein redir, die idr. im fehlerfall mit in den Programmen an extrem vielen Stellen steht und auf eine Fehlerseite umleitet - leider kommt das nicht so selten vor.
        
        Das muss wirklich genau an der stelle beendet werden und darf über return nicht weiterlaufen.
        
        Ich schaue mal weiter.
        
        Danke Marky.
        Mfg
        Markus - http://www.perlunity.de -
        
        +4 replies
        
        Gast wer
        
        2011-07-20 13:11
        
        Nutze goto:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12
        
        while(my $c=CGI::Fast->new()) { # ... Viel alter Code # irgendwo #exit(); goto ENDE; # ... Viel alter Code ENDE: }
        
        Last edited: 2011-07-20 13:21:53 +0200 (CEST)
        
        pq
        
        2011-07-20 13:22
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        und was ist daran besser als next?
        bitte kein goto benutzen.
        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
        
        +2 replies
        
        marky
        
        2011-07-20 14:10
        
        User since
        2003-08-15
        215 Artikel
        BenutzerIn
        
        Hallo,
        
        GOTO wird oft als Lösung angegeben scheint wir aber wirklich die einzigste Möglichkeit zu sein, auch wenn das nicht wirklich schön ist.
        
        Ein next geht ja nur an der stelle - das ganze wird ja aus beliebig tiefen Strukturen aufgerufen und das muss dann egal von wo und wie tief immer an der gleichen Stelle landen und das scheint mir in dem Fall wirklich nur mit einer Sprungmarke zu gehen. Vorallem ist das dann auch einfach umzusetzen, exit durch goto ENDE ersetzen und fertig.
        
        Das probiere ich nachher mal, einer der Befehle die ich bisher wirklich noch nie verwendet habe.
        
        Gruss Marky
        Mfg
        Markus - http://www.perlunity.de -
        
        topeg
        
        2011-07-20 14:58
        
        User since
        2006-07-10
        2611 Artikel
        BenutzerIn
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7
        
        ENDE: while(..) { #... next ENDE; #... }
        
        geht ebenso gut.
        
        +2 replies
        
        kristian
        
        2011-07-20 22:04
        
        User since
        2005-04-14
        684 Artikel
        BenutzerIn
        
        Hallo
        
        Die Diskussion hier macht keinen Sinn solange wir immer an einander vorbeireden.
        Wir werden uns nicht einig solange wir deinen Code nicht kennen und du keinen Code kennst den wir als aktuell und (post)modern verstehen.
        Nimm dir mal ein zwei Tage Zeit und schau dir z.B. Catalyst und Moose an.
        Damit kannst du dann zwar noch nicht wirklich was machen, hast aber eine Ahnung davon, wie es heute aussehen könnte und kannst eher verstehen wie du was "rüber retten" kannst.
        
        Gruß
        Kristian
        
        roooot
        
        2011-07-21 00:27
        
        User since
        2008-03-03
        276 Artikel
        BenutzerIn
        
        Mojo ist meiner Meinung nochmal einen Tick moderner als Catalyst (u.v.a nicht so fett). Mitlerweile gibts dann auch ne vernünftige Docu, man kann also damit arbeiten.
        
        Im Prinzip kommste um ne MVC Architektur nicht mehr rum. Und da ists dann auch kein Ding, das ganze auf FastCGI, CGI, Plack umzubauen...
        Last edited: 2011-07-21 00:29:16 +0200 (CEST)
        Viele Grüße :)
    - +8 replies
    - roooot
      
      2011-07-20 16:37
      
      User since
      2008-03-03
      276 Artikel
      BenutzerIn
      
      Bei mir sieht das wie folgt aus:
      
      Code (perl): (dl )
      
      1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
      
      method run_fcgi { # validate if fast cgi is available try { use CGI::Fast; use FCGI; } catch { print CGI::header; print CGI::div(q{ sorry, fastcgi is not available on this server. (missing CGI::Fast or FCGI - could not be loaded) fix this or run as cgi }); exit; }; # setup disptacher my $disp = $self->_get_dispatcher; $disp->setup; # fcgi loop $ENV{'_persistent'} = 1; while (my $cgi = new CGI::Fast) { $ENV{'_start_time'} = Benchmark->new; # reset timer $ENV{'_persistent'}++; $disp->route($cgi); } }
      
      So wie du siehst, setze ich vor der while Schleife eine Umgebungsvariable $ENV{'_persistent'}. Diese Variable ist ab jetzt IMMER, für jeden Request der kommt 1. Das Hochzählen in der Schleife gibt IMMER, auch nach 100 Aufrufen 2 wieder.
      Our Variablen benutze ich nicht, das widerspricht meiner Ansicht nach sauberem, objektorientiertem Programmieren. Dazu kann ich also nichts sagen.
      
      Ich löse bei mir solche Abbrüche anders. Grundsätzlich so wie Java das vorbgibt: Man hat eine ÜBER Funktion main, die einfach nicht abgebrochen werden darf, bzw von Fehlern nichts mitbekommt.
      Beispielsweise folgender Aufbau:
      
      Code (perl): (dl )
      
      1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
      
      sub main { use Try::Tiny; use CGI; print CGI::header; try { use Foo; Foo->new->dosomething; print "erfolgreich"; } catch { print "fehler: ", $_; } } package Foo; # ... sub dosomething { # ... die "ooops!"; }
      
      main ist hierbei die Funktion in der FCGI-Schleife. Durch den try-catch-Block wird sichergestellt, dass egal was im Programm passiert nie die Schleife beendet wird, bzw das Programm durch die oder irgendwas ähnliches abschmieren kann.
      Will ich nun in einer Unterfunktion abbrechen, kann ich das durch return (im Erfolgsfall) oder die im Fehlerfall. Ein next oder irgendwie sowas brauche ich nicht.
      Fürs debugging bietet sich dann z.b. Devel::StrackTrace an. Ich empfehle aber eine develop Funktion zu haben, die auf try-catch-Block verzichtet und gar nicht erst als FastCGI laufen soll.
      
      Zu SpeedyCGI unter Squeeze: Ich benutze nicht das Debian Perl, sondern ein selbstkompiliertes, etwas aktuelleres ;) Da muss SpeedyCGI dann extra für kompiliert werden. Dazu kommt noch, dass bei mir alles in nem chroot läuft, was die Sache dann nicht einfacher machte ;) Also habe ich auf das alte Stück Käse verzichtet und es richtig gemacht...
      Last edited: 2011-07-20 16:44:37 +0200 (CEST)
      Viele Grüße :)
      - +7 replies
      - marky
        
        2011-07-20 17:20
        
        User since
        2003-08-15
        215 Artikel
        BenutzerIn
        
        Hallo,
        
        danke für den umfangreichen Beitrag, das Error-Modul habe ich mir schon länger angeschaut, dass das komplett mit eval gemacht "gefällt" mir nicht, ich möchte nicht meine 10.000sende Zeile per eval verarbeiten.
        
        Das Problem ist, dass wir den über 10 Jahre alten Code langsam modernisieren, bevor wir diesen jetzt entgültig neu machen. Da ist vieles nicht so ganz einfach.
        
        Aber so läuft das jetzt ohne Probleme, die exits durch Sprungmarken ersetzt und die die's werden sowieso durch ein Modul abgefangen. Die "globalen" Vars sind per local auch begrenzt.
        
        Das Ziel war es ja erstmal das Scripts überhaupt unter so einer Technologie zum Laufen zu bekommen - ohne alles neu zu machen, das hat nun geklappt und zudem wurde gleich ein modularer Cache eingebaut, der unter anderem per memcached läuft - somit ist das "alte" Ding jetzt wirklich sehr performant einsetzbar ohne, das ein riesiger Aufwand notwendig war und jetzt können wir uns an die neuentwicklung des Kernes machen :-)
        
        Gruss Marky
        Mfg
        Markus - http://www.perlunity.de -
        
        +6 replies
        
        roooot
        
        2011-07-20 19:22
        
        User since
        2008-03-03
        276 Artikel
        BenutzerIn
        
        2011-07-20T15:20:34 marky
        Hallo,
        
        danke für den umfangreichen Beitrag, das Error-Modul habe ich mir schon länger angeschaut, dass das komplett mit eval gemacht "gefällt" mir nicht, ich möchte nicht meine 10.000sende Zeile per eval verarbeiten.
        
        Das ist eben eine Einschränkung, mit der man leben muss.
        Python z.B. bietet ja richtig schönes ExceptionHandling an. Liegt wohl einfach in der Natur der Sprache, dass alles ein Object ist.
        Viele Grüße :)
        
        +5 replies
        
        topeg
        
        2011-07-21 01:35
        
        User since
        2006-07-10
        2611 Artikel
        BenutzerIn
        
        2011-07-20T17:22:40 roooot
        Python z.B. bietet ja richtig schönes ExceptionHandling an. Liegt wohl einfach in der Natur der Sprache, dass alles ein Object ist.
        
        Das hat nichts mit der Objektorientierung zu tun, eher damit was man sehen will. Du kannst eine ähnlich ausführliche Meldung auch in Perl bekommen:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
        
        #/usr/bin/perl use strict; use warnings; sub trace { my @lst; my $deep=2; while(my ($package, $filename, $line, $subroutine)=caller($deep++)) { push @lst, "at $filename, Line $line (Package:$package, Sub:$subroutine)\n"; } print STDERR "\n\n",reverse(@lst); print @_ if(@_); } $SIG{__DIE__} = sub{ trace() }; $SIG{__WARN__} = sub{ trace(@_) }; a(); ######################################################################## sub a{ b() } sub b{ c() } sub c{ IN::d() } package IN; sub d{ e() } sub e { warn("UPS"); f(); } sub f{ IN::IN::g() } package IN::IN; sub g{ h() } sub h{ die("BOOM") }
        
        Und es gibt auch Module die das ganze etwas besser handhaben (Das Beispiel oben ist nicht so toll, da z.B. eventuelle andere Handler überschrieben werden.)
        
        +3 replies
        
        roooot
        
        2011-07-21 12:13
        
        User since
        2008-03-03
        276 Artikel
        BenutzerIn
        
        Ich habe mal etwas Zeit mit ExceptionHandling in Perl verbracht, cpan durchsucht.
        Welche try-catch Lösung verwendet denn nicht eval?
        
        Deine Lösung ist natürlich trotzdem nett. Devel::StackTrace gibt allerdings etwas ähnliches aus, man muss eben genauso die SIG überschreiben.
        Das ist aber echt ne gute Idee und ich werde das gleich mal einbauen ;)
        
        modedit Editiert von GwenDragon: Modullink korrigiert
        Last edited: 2011-07-21 12:39:07 +0200 (CEST)
        Viele Grüße :)
        
        topeg
        
        2011-07-21 12:45
        
        User since
        2006-07-10
        2611 Artikel
        BenutzerIn
        
        2011-07-21T10:13:25 roooot
        Ich habe mal etwas Zeit mit ExceptionHandling in Perl verbracht, cpan durchsucht.
        Welche try-catch Lösung verwendet denn nicht eval?
        Du musst "Block-eval" (eval{ ... }) von "String-eval" (eval('...')) unterscheiden das erste verhält sich wie "try" in anderen Sprachen. Es wird keine Interpreterinstanz gestartet. Nur "die" wird dort abgefangen, was einem "throw" entspricht.
        Nur wenn du ein das zweite eval benutzt wird eine neue Interpreterinstanz gestartet und alle Variablen in den neuen Speicherraum kopiert und nach dem eval wenn nötig zurück geschrieben.
        Ich verstehe deine Befürchtungen nicht was eval betrifft. Der Code wird weder langsamer noch wird der Speicherverbrauch signifikant vergrößert, wenn man ein Block-eval benutzt.
        
        2011-07-21T10:13:25 roooot
        Deine Lösung ist natürlich trotzdem nett. Devel::StackTrace gibt allerdings etwas ähnliches aus
        Das war auch nur als Demonstration gedacht. Ich schrieb ja dass es bessere Module dafür gibt.
        
        topeg
        
        2011-07-21 12:53
        
        User since
        2006-07-10
        2611 Artikel
        BenutzerIn
        
        2011-07-21T10:13:25 roooot
        Welche try-catch Lösung verwendet denn nicht eval?
        
        Ich könnte mir etwas mit goto und caller vorstellen, wobei das natürlich wackelig werden kann. Ich sehe aber keinen Grund so was zu schreiben (außer wegen der sportlichen Herausforderung) eval macht das an sich ganz gut.
        
        GwenDragon
        
        2011-07-21 12:38
        
        User since
        2005-01-17
        14748 Artikel
        Admin1
        
        Exception-Class ist auch ein interessantes Modul, um Ausnahmen abzufangen.
        die Drachin Gwen
        
        Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten

View all threads created 2011-06-16 18:26.