Thread CGI Alternative? (25 answers)
Opened by Gustl at 2011-03-14 08:12

clms
 2011-03-14 11:19
#146474 #146474
User since
2010-08-29
373 Artikel
BenutzerIn
[default_avatar]
2011-03-14T08:26:42 Gustl
Aber vielleicht liegts auch am angemieteten Webspace bei all-inkl.!?

all-inkl sollte eigentlich brauchbare Performance liefern, vorausgesetzt der Resourcenhunger Eures Projekts hält sich im Rahmen.

Ich betreue einen Server, der dort gehostet ist und lt. Alexa zu den schnellsten 5% weltweit gehört. (Allerdings sind dafür hauptsächlich statische Seiten verantwortlich. Pro Anfrage müssen nur ein paar
.htaccess-Files ausgewetret werden.)
Aber auch die CGI-Skripte auf diesem Server sind schnell. Lediglich bei 2-3 Maintanance-Skripts merkt man manchmal deutlich, dass sie etwas zu tun haben. Aber das ist auch OK, wenn sie > 10.000 Files durchsuchen müssen.

Bleibt die Frage, warum Eure Seiten so langsam sind. Das kann mehrere Ursachen haben:
1.) die Verbindung zwischen Eurem Client und dem Server
2.) die allgemeine Rechenleistung des Servers
3.) das Laden und Kompilieren Eurer Perl-Skripte
4.) die eigentliche Ausführung Eurer Skripte
5.) der Seitenaufbau in Eurem Browser

Bei Punkt 4 kann man weiter unterscheiden:
4a.) Speicherhunger. Gerät der Server ins swappen?
4b.) Gibt es externe Dinge auf die eurer Skript warten muss, z.B. Datenbanken oder FTP/HTTP-Requests, die Euer Skript startet
4c.) Algorithmische Komplexität. Muss Eure Programm einfach zuviel berechnen?

Punkte 1 und 2 schließe ich normalerweise aus, indem ich die Software erstmal auf meinem lokalen Rechner probiere. Wenn eine PHP-Lösung auf dem all-inkl schnell läuft, könnt ihr das ebenfalls ausschließen.

Punkt 3 könnte es sein, wenn ihr sehr viele Module ladet. GGf. müsst Ihr mal die Zeit für das Laden und Komplieren messen.
Wenn das die Ursache ist, wäre der Umstieg weg von plain CGI zu empfehlen (z.B. auf mod_perl).
Bei Standard-CGI wird das Skript bei jedem Aufruf neu geladen und kompiliert. Bei mod_perl (und anderen Systemen) werden die Skripte schon vor dem Aufruf in den HTTP-Server geladen und kompiliert.

Wahrscheinlich liegen die Performanceprobleme aber bei Punkt 4.
Da müsst Ihr schauen, welcher Teil Eures Codes so viel Rechenzeit bzw. Speicher verbrät. Und dann benchmarken...

Punkt 5 kann sein, wenn Eure Seite nach und nach viele Files nachladen muss, z.B. über Frames oder Javascript.

View full thread CGI Alternative?