nicht angemeldet
Hallo!
Nur mal so nebenbei, ich spiele hier eigentlich nur rum, ich weiß weder ob ich das irgendwann mal einsetzen werden, noch weiß ich welchen Geschwindigkeits-Vorteil dieses Vorgehen genau bietet.
Hierzu sind ausgiebige Tests mit guten Testdaten in einer Testumgebung der tatsächlichen Applikation notwendig. Leider habe ich im Moment keine Möglichkeit eine entsprechende Umgebung zu schaffen in der ich den Testserver wirklich mit Anfragen auslasten kann. Ich werde es aber sicher demnächst so durchführen, sobald sich die Möglichkeit bietet. Und da werde ich auch einige andere Dinge testen wie Apache 1.3 vs 2.0, statische Inhalte auf einer Ramdisk...
Finde ich gegenüber dem Erstellen einer "komplexen HTML-Tabelle" ganz und gar nicht aufwendig. Aber genau da besteht vielleicht auch Dein Problem: Du wirfst alles in einen Pott, ist ein Teil des PHP-Skriptes nicht zu gebrauchen, muß gleich der ganze PHP-Interpreter über Bord (übertrieben ausgedrückt).
Ich versuche lediglich, so früh zu optimieren, wie eben möglich. Was habe ich davon erstmal zig Sachen zu laden, die Last verursachen, wenn ich dem Server diese Arbeit doch zum großen Teil ersparen kann?
Mir geht es nicht um ein spezielles Problem, sondern ich wollte mal ein paar allgemeine Meinungen zur Idee einholen.
Warum sollte ich das alles nicht vermeiden - wenn es doch geht?
Siehst Du, "wenn es doch geht". Nur weil es geht, muß es ja noch lange nicht sinnvoll sein, oder?
Ja, also am besten CGI verwenden...? Warum überhaupt Gedanken über Performance machen? Man kann doch mal ein bisschen rumspinnen, oder? ;-)
Ich kenne die Killerapplikation nicht, an der Du werkelst, aber ich habe den Eindruck, daß Du versuchst, geradezu krampfhaft mit Kanonen auf Spatzen zu schießen, und zwar in zweierlei Hinsicht:
Warum "Killerapplikation"? Wie gesagt, es sind Ideen. Es ist doch nichts schlechtes die Performance mit den gegebenen Mitteln best möglich auszureizen, oder?
Wenn ich doch genau weiß dass viele Seiten sehr oft aufgerufen werden, um zu sehen ob sich was geändert hat, ist es doch das einfachste dem Client so lange die im Cache gespeicherte Variante verwenden zu lassen, und nur bei Änderungen die eigentliche Applikation zu bemühen. Durch Verwendung der SessionID behalte ich darüber hinaus sämtliche Rechte-Strukturen der Applikation, ggfs. kann ich bestimmte Seiten auch global speichern, mal sehen wie ich das noch einbaue. Und das ließe sich auch mit einem HTML-Cache verbinden.
- Du scheinst gar keine genaue Vorstellung davon zu haben, wie groß das Ziel ist und wie es sich bewegt und bestellst deshalb einfach mal das größte, modernste, austattungsreichste Waffensystem, das Du gerade kriegen kannst.
Muss man das denn immer? Wenn ich sehe dass mit (IMHO) halbwegs vergleichbaren Maßnahmen Einsparungen um den Faktor 10-50 realisiert werden, ist das für mich durchaus ein Gebiet, wo es sich löhnt mal drüber nachzudenken, auch ohne eine konkrete Problemstellung. Wenn ich ein bisschen getestet habe kann ich später bei Problemen ggfs. hierauf zurückgreifen.
Warum? Hast Du überhaupt mal nachgemessen, wie lange es dauert, bis PHP Dein Skript ausführbar vorliegen hat? Das Problem an Deinem Skript ist das Zusammensuchen und Aufbereiten der Daten, nicht das Laden des Skriptes ansich. Das hast Du jedenfalls so mit der Aussage "je größer die Datenbank, desto langsamer die Ausgabe" behauptet.
In dem oben verlinkten Artikel wurde ein Faktor von 15 zwischen statischer Seite und einem Hello-World Script(!) gemessen. Und von solchen Größenordnungen habe ich schon mehrfach gehört. AFAIK sind die Unterschiede beim Apache ein wenig kleiner. Auf der anderen Seite verwende ich aber keine statische HTML-Seite, sondern nur einen File-System-Check und einen 304 Header, was sicher schneller ist als statisches HTML. Dazu kommt dass der Client die Daten meist aus dem eigenen RAM holen kann. Außerdem sind meine PHP-Scripte keine Hallo-Welt Scripte, und auch PHP-Scripte die den Cache-Status prüfen(per DB) brauchen sicher ne Ecke mehr Performance, auch durch das Framework...
Wie gesagt nicht selbst gemessen, das werde ich nachholen.
Anstatt nun erstmal diesen aufwendigsten Teil zeitweise (also per Last-Modified) überflüssig zu machen, baust Du noch eine detailreiche Konstruktion obendrauf, um gleich das ganze Skript zu eliminieren. Damit schießt Du IHMO weit über das Ziel hinaus und baust Dir gleichzeitig haufenweise Fehlerquellen ein (wie Du ja selbst bemerkt hast).
Die Fehlerquellen bei der von dir beschriebenen Methode sind dieselben. Es reicht meist nicht das prüfen eines Timestamps, es sind mehrere Prüfungen notwendig. Z.B. wird die genannte HTML-Tabelle aus ich glaube 5 Datenbank-Tabellen erzeugt. Das können unter Umständen 1000 Datensätze und mehr sein. Das heißt ich müsste die alle Datensätze prüfen, bei jedem Aufruf. Ja, das geht mit wenigen SQL-Statements, aber auf der anderen Seite, gibt es nur 2 Scripe die Änderungen an den entsprechenden Daten vornehmen können, also ist es IMHO effizienter hier anzusetzen.
Der Anteil an der gesamten Abwicklungsdauer, den PHP zum Laden des Skriptes beansprucht, mag beim Endbenutzer mit einigen hunderstel oder meinetwegen zehntel Sekunden vielleicht noch messbar sein, aber ich kann mir nicht vorstellen, daß er noch irgendwie _merk_bar ist.
Gut, es gibt 2 Probleme, das eine sind besonders Lastenintensive scripte wie das beschriebene, wenn es nur darum ginge dieses Problem zu lösen würde Deine Methode prinzipiell reichen. Das andere Problem ist ein insgesamt hohe Last des Webservers/DB-Servers. Und wenn ich hier Verbesserungen erzielen will muss ich mit den Optimierungen früher ansetzen. Aber wie gesagt, es ist erstmal nur eine Idee, die ich evtl. zu einem Framework ausbauen könnte. Ich könnte auch spezielles Apache-Modul programmieren, welches hierfür optimiert ist. Sowas haben die Leute aus den verlinkten Vorträgen gemacht, wenn auch nicht für den Apache, aber die Vorträge sind sehr interessant und lesenswert wie ich finde.
Von daher scheint mir der Aufwand, den Du betreibst, sinnlos.
mag sein.
- Du versuchst, mit eine bestimmte Aufgabe zu erledigen, bedienst Dich dabei aber eines für diesen Zweck unzureichenden Werkzeugs.
Ich versuche keine bestimmte Aufgabe zu erledigen, ich versuche eine Idee zu verwirklichen, bzw. ein Konzept von einem anderen (extrem auf Performance getrimmten) Webserver zu mit Apache-Bordmitteln zu realisieren.
Warum? Deinen Ausführungen nach zu urteilen ist die ganze Angelegenheit fürchterlich komplex.
Meinst Du meine Caching-Idee? So komplex ist das nicht, die Komplexität entsteht durch dei Komplexität der Applikation, und hier habe ich bei allen Caching-Mechanismen dieselbe oder zumindest ähnliche Probleme.
Interpretersprachen waren noch nie für komplexe Aufgaben zu gebrauchen und werden es nie sein,
Ja? Das sehe ich anders. Mit PHP lassen sich auch recht komplexe Anforderungen erfüllen, genauso wie man mit Sprachen wie Java oder C++ extremen Müll fabrizieren kann. PHP bietet eigentlich alles was man für komplexe Applikationen braucht, vielleicht bis auf einen brauchbaren Applikationsserver, aber auch hier kann man sich mit einem eigenen Framework viel erreichen. So bieten einige Opcode-Caches z.B. die Möglichkeit Datenstrukturen im SHM zu speichern, und das funktioniert sehr gut. Man muss nur wissen was man tut. Das Problem ist, dass sich sowas nicht so ohne weiteres auf mehrere Maschinen verteilen lässt, wie J2EE Application-Server, und hier kommen dann wieder die Performance-Optimierungen ins Spiel, mit dessen Hilfe man die Leistungsfähigkeit deutlich erweitern kann, und eben in der Richtung habe ich ein bisschen rumprobiert, bzw. bin ich noch dabei.
egal wie c00l das Dingens gerade ist, insofern benutzt Du mit PHP möglicherweise schlichtweg das falsche Werkzeug.
Wie kommst Du jetzt auf einmal auf eine "PHP ist doof" Diskussion? Mich würde ganz ehrlich sehr interessieren warum Du PHP in komplexen Web-Applikationen nicht für das geeignete Werkzeug hältst. Was wären denn entsprechend brauchbare Werkzeuge Deiner Meinung nach?
Ich höre andauernd "PHP ist für sowas doof", "Java ist sowieso doof", aber was verwenden solche Leute denn bitte?
Oder, so würden es die SelfSpezialisten sehen, Dein Server ist zu lahm. Kommt im Endeffekt auf das gleiche raus.
Hä? Was ist das denn jetzt für eine Anspielungen? Die Software des Self-Server lässt sich wohl kaum noch nennenswert optimieren. Oder sollte alles mit Assembler geschrieben werden?
Was habe ich von statischen HTML-Seiten? Was ist daran besser die im Server-Cache zu lagern, als im Cache des Client?
Das hat überhaupt nichts mit einem Server-Cache zu tun (der in den meisten Webservern eh nicht vorhanden ist), eine statische Seite muß schlichtweg nicht bei jedem Aufruf neu erstellt werden. Und der Webserver ist zudem in der Lage, den ganzen Tralala mit Last-Modified ganz von alleine zu handhaben.
Wenn Du aber die Entscheidung ob cachen oder nicht in ein PHP-Script verlagerst ist der Server eben nicht in der Lage irgendwelche Caching-Mechanismen zu handhaben, ganz im Gegenteil sendet der server aggressive anti-caching Header um eben solches zu verhindern(sobald man sessions einsetzt).
Und wenn Du aus PHP-Scripten HTML-Dateien erzeugst und zwischenspeicherst, dann ist das für mich auch eine Art des Caching.
Es mag Dir entsetzlich simpel vorkommen, aber das ist letztenendes genau das, was Du haben willst: keine Datenbankaufrufe, kein PHP, nicht einmal mod_rewrite. Daß auch solche statischen Seiten (in einem gewissen Rahmen) persönlich eingerichtet werden können, schrieb ich ja bereits.
Aber woher weiß der Webserver ob sich irgendwas an der Ausgabe der PHP-Scripte geändert hat?
Grüße
Andreas