nicht angemeldet
Moin!
ich habe bereits mein ursprüngliches script von php ins perl gecodet, da ich annahm, daß es schneller sei.
Vermutlich wird dies nicht der Fall gewesen sein - ich kann mir sogar vorstellen, dass es schlechter geworden ist. Perl wird üblicherweise als CGI eingesetzt, die CGI-Schnittstelle ist aber für sich recht langsam. PHP hingegen _kann_ als Apache-Modul laufen und hätte deswegen leichte Vorteile. Allerdings gibt es auch mod_perl, damit Perl als Apache-Modul laufen kann. Dazu sind aber wieder gewisse Programmiertechniken notwendig, damit es funktioniert. Denn das Script wird bei mod_perl nur noch einmal kompiliert und dann immer wieder verwendet - Änderungen am Skript sind nur durch einen Serverneustart wirksam zu machen, für die Entwicklung von Skripten ist das eher hinderlich.
Ich denke aber, dein Problem liegt nicht an den Skripten.
nun überlegte ich dieses script zu vervieltätigen um eventuell ein paar prozente der ressourcen einzusparen.
Wozu? Wenn ein Browser einen Request an ein Skript schickt, wird eine Kopie des Skriptcodes von Festplatte gelesen (bzw. auch aus dem Speicher genommen), kompiliert/interpretiert und ausgeführt. Wenn zwei Anfragen von zwei Benutzern gleichzeitig eintreffen, sind _zwei_ Skripte parallel aktiv. Es läuft bereits das ab, was du meinst einbauen zu müssen.
Es ist nicht sinnvoll, dieses Skript irgendwie aufzuteilen. Es muß ein Skript bleiben, denn die Ausgabe an den Browser muß ja eine komplette Seite sein, und nicht nur ein Bruchstück.
das script stellt on-th-fly (mit jedem http request) eine eigenständige webseite für den user her, die er selbst sich zusammenstellt und die stets variert,da ich eine breite pallette anbiete, kann man davon ausgehen, daß in seltensten fällen, mehrere requests über das script die selbe ressorce anfordern(z.B. der eine generiert sich sein wetter, und der andere sein neues tv-programm.)
Dann greift das Skript doch sicherlich auf irgendwelche Datenbestände zu. Wie sind die gespeichert? Wie greift das Skript zu? Üblicherweise läßt sich hier durch Implementation von geeigneten Mechanismen (Caching, Indizierung) die Zugriffsgeschwindigkeit erhöhen, was natürlich die Bearbeitungszeit des Skripts senkt.
es funktioniert alles einwandfrei, leider ist aufgrund des traffic aufkommens der server langsam am limit angekommen.
Du solltest sehr genau analysieren, wo der Flaschenhals steckt, damit du an dieser Stelle die Performance verbesserst.
Dieses Forum hier hatte vor einiger Zeit mit der alten Forumssoftware ebenfalls erhebliche Performanceprobleme. Der Grund lag wohl unter anderem darin, dass beim Speichern eines Postings viele Dateien auf Festplatte für weitere Zugriffe gesperrt werden mußten, und diese Sperre relativ lange andauerte. Außerdem war das Forum komplett in Perl geschrieben und mußte XML-Dateien parsen, was offensichtlich nur bis zu einem gewissen Grade performant war. Das jetzige Forum ist in den performancekritischen Teilen in C geschrieben, besitzt jetzt einen eigenen Forums-Daemon (Serverprogramm, der im Hintergrund läuft) und hält alle häufig nachgefragten Daten im RAM bereit. Speicherung auf Festplatte passiert in regelmäßigen, aber nicht so häufigen Abständen. Außerdem sind die Sperrzeiten beim Abschicken eines Postings wesentlich verkürzt worden. Alle diese Verbesserungen konnten nur erfolgen, nachdem die Problempunkte des alten Forums analysiert waren.
soweit ich dich versatnden habe, gibt es keine gleichzeitigkeit(zumindest bei einer einzigen CPU), so daß es wohl unter umständen kein vorteil bringen würde, mehrere gleiche scripte die requests abarbeiten zu lasssen.
Es macht beispielsweise Sinn, mehrere Aufgaben gleichzeitig zu starten, wenn bei diesen Aufgaben in irgendeiner Art und Weise auf etwas gewartet werden muss und die Wartezeit nicht anderweitig sinnvoll genutzt werden kann. Wenn du von fremden Servern irgendwelche Seiten abrufst, dann ist es vorteilhaft, von mehreren Servern parallel Seiten abzurufen, weil der Empfangsvorgang in der Regel eine Weile dauert - während die eine Aufgabe auf Daten wartet, kann die andere Aufgabe schon den nächsten Request losschicken, und die dritte Aufgabe die gerade empfangenen Daten speichern.
Wenn die Aufgabe allerdings darin besteht, eine lokale Datenbank zu befragen, dann sind viele parallele Anfragen an die Datenbank für die Performance vielleicht eher hinderlich, weil ja nicht nur die Aufgabe von deinem Server bearbeitet werden muss, sondern auch noch die Datenbankabfrage Prozessorpower kostet - ganz zu schweigen von den möglicherweise notwendigen Festplattenzugriffen, um überhaupt an die Daten der Datenbank ranzukommen.
ursprünglich habe ich mir das folgendermaßen vorgestellt, mit jedem request wird ein anderes script aufgerufen.
zur zeit geht jeder request über script A.
mit einem simplen zufallsgenarator könnte ich jedem neuen request ein anderes script zuweisen.(A1, A2, A3, A4 u.s.w.[wobei A1-A(x) identische scripte sind]).
Wenn A1, A2, A3 exakt das gleiche tun sollen - wozu sie dann kopieren? Das erledigt, wie oben erwähnt, der Server bereits für dich: Die Skripte laufen parallel.
Allerdings laufen natürlich nur soviele Skripte parallel, wie Serverinstanzen parallel laufen dürfen. Das bedeutet: Es gibt eine Obergrenze an parallel verarbeitbaren Browser-Requests. Wenn diese Obergrenze zu niedrig gewählt ist, hast du viel freien Speicher, viel übriggebliebene CPU-Zeit, und eine wahnsinnige Warteschlange an Browsern, die was von deinem Server wollen.
Wenn hingegen diese Zahl zu hoch gewählt ist, hast du kaum noch RAM-Speicher frei, die CPU ist dauernd zu 100% ausgelastet, und dein Server pfeift aus diesem Grunde auf dem letzten Loch. Dann sollte man vielleicht über mehr RAM, effizientere Programmierung, eine schnellere Festplatte, oder sogar eine schnellere CPU nachdenken (in dieser Reihenfolge). Ohne Analyse, wo dein Problem liegt, geht das aber nicht.
- Sven Rautenberg
Diese Signatur gilt nur am Freitag.