nicht angemeldet
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.
Naja, ein etwas merkwürdiges Vorgehen. Wenn ich an etwas bastel, dann möchte ich schon gerne wissen, warum ich das mache und vor allen Dingen ob ich meine Ziele erreiche.
Aber wenn es Dir Freude macht, einfach ziellos in der Gegend rumzubasteln, bitte ;)
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?
Gegenfrage: Was habe ich davon, zig Sachen zu programmieren, wenn ich am Ende nicht merke, überhaupt etwas gemacht zu haben?
Es ist eine Abwägung zwischen Komplexität und Geschwindigkeitsvorteil. Mir persönlich erscheint Deine Vorgehensweise viel zu aufwendig und -wichtiger- fehlerträchtig, relativ gesehen zum tatsächlichen, absoluten Geschwindigkeitsvorteil.
Man könnte die Geschichte auch noch auf die Spitze treiben und sagen, daß das, was Du an Personalkosten für Optimierungen verursachst, nie und nimmer auf der Hardwareseite eingespart werden kann.
Aber anscheinend reden wir auch etwas aneinander vorbei: Ich hatte angenommen, Du hast ein Problem mit einer realen Anwendung, Du hingegen probierst lediglich. Daß jemand, der ein Alltagsauto im Sinn hat, andere Entwicklungsmaßstäbe ansetzt als jemand, der eine Formel-1-Karre bastelt, ist natürlich klar.
Insofern sind Deine Ansätze natürlich vollkommen legitim, ich hinterfrage lediglich die Zweckmäßigkeit für den Alltag.
Mir geht es nicht um ein spezielles Problem, sondern ich wollte mal ein paar allgemeine Meinungen zur Idee einholen.
Wie gesagt: Zu aufwendig (im Sinne von umfangreich), daher auch zu fehlerträchtig, und das bei zu wenig realem (im Sinne von absolut) Geschwindigkeitsvorteil.
- Du scheinst gar keine genaue Vorstellung davon zu haben, wie groß das Ziel ist und wie es sich bewegt
Muss man das denn immer?
Nein, nicht immer, aber es ist im Allgemeinen schon sinnvoll, zu wissen, was man attakiert - selbst wenn man nur forscht.
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,
Faktoren sind relativ. 10 bis 50 sieht für sich alleine gut aus, zugegeben, aber ist das auch noch der Fall, wenn es um kokrete Zahlen geht, beispielsweise die Entscheidung zwischen 0.1 oder 5 Tausendstel Sekunden? Und das insbesondere angesichts der Tatsache, daß das Programm nach dem 0.1 oder 5 Millisekunden-Start eine halbe Minute läuft, weil es soviele Daten verarbeiten muß?
Aber wie gesagt: Du hast einen anderen Blickwinkel angesetzt als ich.
verwende ich aber keine statische HTML-Seite, sondern nur einen File-System-Check und einen 304 Header, was sicher schneller ist als statisches HTML.
Nein, da befindest Du Dich nun wirklich auf dem Holzweg. Der Apache liest von ganz alleine die Dateiinfos und sendet dann gegebenenfalls ein Not Modified. Ausgelesen wird die Datei nur, wenn es wirklich sein muß.
Bei einer statischen Datei betreibst Du also einen noch größeren Aufwand: Beide Varianten (Apache alleine sowie Apache plus Deine mod_rewrite-Konstruktion) prüfen das Änderungsdatum der Datei, Du bringst hingegen auch noch mod_rewrite ins Spiel.
Dazu kommt dass der Client die Daten meist aus dem eigenen RAM holen kann.
Der Client hat damit nichts zu tun, ob er nun von mod_rewrite oder von PHP ein Not Modified geschickt bekommt, ist ihm vollkommen wurscht, er weiß es nicht einmal.
Warum? Deinen Ausführungen nach zu urteilen ist die ganze Angelegenheit fürchterlich komplex.
Meinst Du meine Caching-Idee?
Nein, die Anwendung, die die Daten sammelt und ausgibt.
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.
Interpretersysteme haben grundsätzlich den Nachteil, daß sie bei jeder Ausführung neu interpretiert, also in entsprechende Anweisungsblöcke für den Prozessor übersetzt werden müssen. Das gilt auch, wenn der Programmcode vorverarbeitet in einem Cache zwischengespeichert wird, denn auch hier muß immer noch eine Anweisungsliste umgesetzt werden. Dazu kommt, daß durch die Vereinfachung, die den meisten Interpretersprachen zu eigen ist, auf die Hardware abgestimmte Optimierungen nur schwerlich möglich sind.
Liegt das Programm hingegen bereits in Maschinencode vor, also als ausführbare Binärdatei, wird dieser Arbeitsaufwand des Interpreters komplett gespart.
Das soll nun aber nicht automatisch bedeuten, auf eine CGI-Anwendung zu wechseln; da kann man vom Regen in die Traufe kommen. Ideal wäre hingegen ein eigenes, echtes Apache-Modul.
Mit "komplex" meine ich weiterhin nicht unbedingt "umfangreich", also viele Seiten und Funktionen umfassend, sondern vielmehr die reine Masse an Aufgaben, die hintereinander abgearbeitet werden muß, die reine Ausführungsgeschwindigkeit.
Versuche mal, mittels PHP eine Grafikdatei pixelweise zu bearbeiten, zum Beispiel ein Mosaik daraus zu machen. Das ist eine einzelne Aufgabe, also ganz und gar nicht umfangreich, aber sie erfordert doch die Berechnung einer großen Menge Daten. Während ein ausführbares Programm fröhlich die hunderttausendste Grafik verwurstet, wirst Du mit PHP (lies: einem Interpretersystem) schon an der ersten verzweifeln.
Nebenbei: Java ist von Haus aus auch eine Interpretersprache.
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?
Wo habe ich bitte geschrieben, daß PHP doof sei? Es gibt Anwendungsgebiete, auf denen ein System X einfach nicht mit einem System Y mithalten kann. Punkt, so ist das nunmal.
Mit meiner Anmerkung "egal wie c00l" wollte ich in gewisser Hinsicht genau auf Deine obige Reaktion abzielen: Anstatt die Grenzen von PHP anzuerkennen wird dieses System auf Teufel komm raus verteidigt. Damit fällt man aber früher oder später auf die Nase.
Das ist übrigens nicht auf PHP beschränkt, das gleiche ist den Leuten passiert, die vor Jahren mit Java ein komplettes Office-System geschrieben haben: War ganz fürchterlich c00l und modern, weil Java seinerzeit gerade ganz krass mega-in war - aber wer damit einen simplen Brief schreiben wollte, hat sich lieber die olle Schreibmaschine aus dem Schrank geholt.
Interpretersysteme, auch PHP, haben den großen Vorteil, daß man mit ihnen einfach und schnell bestimmte Aufgaben programmieren kann. Der Nachteil ist, daß diese Aufgaben bei weitem nicht so schnell erledigt werden können wie mit Maschinencode.
Und bevor Du Dich weiter auf irgendeine bestimmte Sprachform festlegst: Auch Assembler kann schneckenlangsam sein, wenn man es nicht wie üblich in Maschinencode übersetzt, sondern einen Assembler-Interpreter verwendet.
Und wenn Du aus PHP-Scripten HTML-Dateien erzeugst und zwischenspeicherst, dann ist das für mich auch eine Art des Caching.
Ja, richtig, und? Das habe ich doch eingangs als Alternative vorgeschlagen: Bei Änderung der Daten neue HTML-Dateien erstellen und die persönlichen Vorlieben (z.B. das Datumsformat) per Javascript außerhalb des Servers umsetzen.
Gruß,
soenk.e