Bei meinen Tests wollte ich herausfinden, welche Arten von CGI-Programmen effiziente Generatoren für Website-Content sind. Dafür mussten faire und klar definierte Vorgaben für die Performance gemacht werden, was verlangte, alle Faktoren auszuschließen, die die gewünschte Messung der Performance beeinträchtigen konnten. Einer dieser Faktoren war die Ladezeit einer Website. Diese wird von einer Reihe von Bedingungen beeinflusst – z.B. Geschwindigkeit des Client-Computers, Caching, Netzwerk-Latenz und Webserver-Konfiguration. Hier noch ein paar weitere Faktoren, die Einfluss auf die Performance haben:
Datenbank-Performance und Netzwerk-Latenz
Der Zugriff auf Datenbanken ist einer der Hauptengpässe bei der dynamischen Erstellung von Websites und sollte nicht auf die leichte Schulter genommen werden. Für diesen Test mussten deshalb die Datenbankzugriffe für alle drei Technologien identisch sein. Der Verzicht auf Datenbankzugriffe beseitigte einen irrelevanten und unfairen Performance-Nachteil und vereinfachte außerdem die Test-Skripts. Also blieben Datenbankzugriffe in diesem Fall außen vor. Sollte sich herausstellen, dass die Zeit für die Seitenerstellung im Vergleich zur Zeit für Datenbankzugriffe zu vernachlässigen ist, wäre man sich dieser Tatsache zumindest sicher und könnte sich bei der weiteren Performance-Analyse wieder der Datenbankseite zuwenden.
Die Erfahrung sagt einem, dass Netzwerk-Latenz und Datenbankzugriff ernste Engpässe für CGI-generierte Websites darstellen, aber man kann immer nur eine Sache zur Zeit testen. Für einen Webserver mit hoher Prozessorlast kann es durchaus sinnvoll sein, sich zuerst um eine Verbesserung der Seitengenerierung zu kümmern.
Die Perl Scripting-Umgebung
Einer der relevanten Aspekte bei der Seitenerstellung ist die Perl Scripting-Umgebung. Auf einem Webserver können Perl CGI-Skripte als eigene Prozesse laufen (Standalone) oder innerhalb des Apache mod_perl-Moduls. Mit mod_perl werden Skripte wiederverwendet, ohne jedes Mal neu initialisiert zu werden. mod_perl stellt im Vergleich zu Perl als Einzelanwendung eine schnellere Umgebung zur Ausführung bereit. Da es hier um die Performance geht, ist dies eine gute Gelegenheit, um zu sehen, ob mod_perl Vorteile bringt. Deshalb muss man sowohl mit als auch ohne mod_perl testen.
Festplattenzugriff und Caches
Außerdem sind da noch die bekannten Problempunkte Festplattenzugriff und Caches. Festplatten sind so langsam im Vergleich zu RAM-Speicherzugriffen und CPU-Geschwindigkeiten, dass schon die kleinste Beeinträchtigung vonseiten der Festplatte jede Performance-Information erheblich stören kann. Für einen geschäftigen Webserver ist der Festplattenzugriff kein Problem – alle relevanten Informationen sollten im Cache zwischengespeichert werden. Ginge es um Datenbankzugriff oder Taktzeit (Start-Stop-Time), müsste man Festplattenzugriff berücksichtigen. Bei normalen Systemen mit sog. ‚Steady State‘ sollte das jedoch nicht der Fall sein.
Und schließlich geht es hier nicht um einen systemweiten Test der Gesamtbelastung durch bestimmte Anwendungen. Im Moment wollen wir eigentlich nur Kriterien für die Auswahl einer bestimmten Technologie herausfinden, und irgendwo muss man ja anfangen.
Schon im April 2025 soll Android 16 den Status Plattformstabilität erreichen. Entwicklern gibt Google danach…
Die Hintermänner setzen KI-Chatbot-Tools als Köder ein. Opfer fangen sich den Infostealer JarkaStealer ein.
Vernetzte Produkte müssen laut Cyber Resilience Act über Möglichkeiten zur Datenverschlüsselung und Zugangsverwaltung verfügen.
Das jüngste Update für Windows, macOS und Linux stopft drei Löcher. Eine Anfälligkeit setzt Nutzer…
Zwei von Google-Mitarbeitern entdeckte Schwachstellen werden bereits aktiv gegen Mac-Systeme mit Intel-Prozessoren eingesetzt. Sie erlauben…
Die Hintermänner haben es unter anderem auf Daten von Facebook-Geschäftskonten abgesehen. Opfer werden über angebliche…