CGi via python -m CGIHTTPServer 8000 langsam

  • Hallo,

    bei Versuchen mit CGI (python -m CGIHTTPServer 8000) + C fiel mir auf, dass es deutlich länger braucht (>1000ms), das die Ergebnisseite eines CGI scripts beim Browser ankommt. als der direkte Aufruf einer entsprechenden Seite ohne CGI Nutzung (getestet mit Firefox + Explorer):

    Seite via CGI script >1000ms
    Direkter Seitenaufruf: <100ms
    Dateigröße < 1kByte

    Wobei die Ausführung des C-Programms nur ein paar ms braucht.

    Ich habe zwar schon in diversen Beiträgen gelesen, dass CGI nicht besonders schnell ist (u.a. weil wohl pro Aufruf ein neuer Prozes erstellt wird), das es aber in dem Bereich von 1 Sekunde ist überrascht mich. Habt ihr ähnliche Erfahrungen gemacht oder eine Idee, wo es hakt?

    (ich denke zwar nicht, dass es ein Netzwerkproblem ist, da ich lokal über localhost die selbe Zeitdifferenz habe. Ich habe aber trotzdem raspiNetInfo.txt angehängt)

    Vielen Dank!

    absalom

  • Servus absalom,


    ... (u.a. weil wohl pro Aufruf ein neuer Prozes erstellt wird)...
    ...


    ein neuer Prozess wird in beiden Fällen erzeugt. Allerdings kann ein kompiliertes Programm direkt ausgeführt werden, während für Python erst der Interpreter geladen und gestartet werden muss, der dann erst das script überprüft, interpretiert und ausführt.
    Ich denke, die Erklärung ist - im Groben - schon richtig.

    cu,
    -ds-

  • Kannst du mal zeigen, was genau du da tust? Denn in deinem Fall wird der Python-Interpreter eben genau *nicht* geladen, gestartet & dann ein Programm ausgefuehrt. Sondern Python *ist* der CGI-Server. Aber ein C-Programm fuehrt der so ohne weiteres ja nicht aus. Wie sieht dann also das eigentliche CGI-Skript aus?

  • Es ist richtig, dass Python der CGI-Server ist und das kompilierte C-Programm ausführt. Dieses C-Programm erzeugt über printf's die HTML Seite, die dann (von Python) zum client geschickt wrd.

  • Autsch. Warum tust du dir das an, CGI in *C* zu programmieren? Oder ueberhaupt CGI? Aber sei dem wie es ist - erstmal sehe ich keinen Grund, warum das so langsam ist, nur weil Python hier im Spiel ist. Anderen Prozess forken, ein bisschen IO - das sind duenne Schichten ueber den C-Funktionen des OS, da wird nicht viel gefressen.

    Hast du mal probiert NGINX oder Apache zum ausfuehren deines CGIs zu benutzen? Und umgekehrt mal ein simples Python-Programm mit Shebang, ausfuehrbaren Rechten & auch per print ausgegebener HTML-Seite?

  • Ich hatte zumindest schon mal lighttpd als CGI Server getestet. Da konnte ich keine relevanten Geschwindigkeitsunterschiede sehen. Das auszuführende C-Programm durch Python zu ersetzen habe ich noch nicht getestet. Ich habe da zwar wenig Hoffnung, werde es aber trotzdem ausprobieren.

    offtopic: Meine Anwendung ist eine Motorsteuerung für eine Beschattung. Ein Daemon steuert die HW Schicht. Für die Inteaktion mit dem Benutzer habe ich HTML verwendet. Da die resultierende Seite von den Benutzereingaben und dem Motorstatus abhängig ist, empfand ich CGI als eine elegante Möglichkeit dynamisch die HTML Seite zu erstellen. Und da ich C kenne, hat es sich für mich angeboten. Nach einiger Zeit hat sich herausgestellt, dass die HTML Seite während der Nutzung unverändert bleiben kann und die dynamischen Elemente besser via JavaScript anpassbar sind. D.h. der Server bzw. mein CGI Script erzeugt nur noch eine JavaScript Konfiguration, die zum Client gesendet wird.

    Im Endeffeekt sieht es nun so aus:

    • Webbrowser schickt Anforderung zum Server
    • C Programm (vom Server gestartet) schickt Anforderung an Daemon über pipes
    • Daemon liest / schreibt HW
    • Daemon gibt Status an C Program zurück
    • C Programm erzeugt eine JavaScript Konfiguration
    • Server schickt diese JavaScript Konfiguration zum Webbrowser, der sie dann lokal ausführt
  • @absolom: mir ging es nicht um Ersetzung, sondern ein einfaches Test-Programm, so dass du eine Umgebungsbeeinflussung von CGI zu deinem C-Code ausschliessen kannst, bzw. der auf den Grund gehen. Also einfach

    Python
    #!/usr/bin/python
    print "Content/type: text"
    print
    print "Hallo"

    oder so etwas.

    Letztlich hast du ja ein ziemlich gutes Design - Daemon + Pipes. Ich wuerde da einfach gleich in Python einen Webserver schreiben, zB mit dem bottle-Mini-Rahmenwerk, und dann sparst du dir den ganzen Server/CGI-Aufriss. Das kann auch problemlos statische Dateien ausliefern, und hat ein kleines Templating-System an Bord.

    Oder halt Python ganz raus, und gleich light-httpd. Mir ist auch noch nicht ganz klar, warum du den mal hattest und jetzt auf Python CGI gewechselt hast.

  • Ihr habt mich auf den richtigen Weg gebracht. Das Problem sitzt mal wieder vor dem Bildschirm. Ich dachte, dass mein C-Programm nur ein paar ms braucht - das war aber die konsumierte CPU Zeit, da es 99% der Zeit mit Warten auf einen Temperatursensor verbringt. Im echten Leben wird es erst nach etwa 1 Sekunde beendet.

    Ich habe zwischenzeitlich beide Ansätze versucht:
    1) ein kleines CGI-Script (Perl) mit dem Python Server -> ging ruckzuck
    2) ein kleines CGI-Script (Perl) mit Apache -> ging noch etwas schneller

    Zum Schluss dann natürlich auch mein C-Programm ohne die Warterei auf den Temperatursensor -> deutlich unter 100ms.

    Vielen Dank für Eure Beiträge! Nun kann ich - falls diesen Sommer noch mal die Sonne rauskommt - die Beschattung meiner Terasse übers Handy entspannt steuern.

    Grüße
    absalom
    Automatisch zusammengefügt:


    Letztlich hast du ja ein ziemlich gutes Design - Daemon + Pipes. Ich wuerde da einfach gleich in Python einen Webserver schreiben, zB mit dem bottle-Mini-Rahmenwerk, und dann sparst du dir den ganzen Server/CGI-Aufriss. Das kann auch problemlos statische Dateien ausliefern, und hat ein kleines Templating-System an Bord.

    Oder halt Python ganz raus, und gleich light-httpd. Mir ist auch noch nicht ganz klar, warum du den mal hattest und jetzt auf Python CGI gewechselt hast.

    ich hatte mit dem Python CGI gestartet, weil es sehr einfach aufzusetzen war (das waren meine ersten Schritte mit dem Raspi und HTML). Lighttpad hatte ich danach kurz getestet, um einen Geschwindigkeitsvergleich zu haben. Das bootle framework sieht auf den ersten Blick genau nach dem aus, was mir eine Menge Arbeit erspart hätte - werde ich mir noch genauer zu Gemüte führen - danke für den Tipp!

    Einmal editiert, zuletzt von absalom (13. Juni 2016 um 23:00)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!