Perform.-Vgl.: Grafik generieren vs. File lesen (lohnt caching?)

[&69lig;]

Nahmd nochmal...

(zuerst: es kann ganz schön schwierig sein, das Topic in so'n paar Zeichen zu quetschen :-)

Also, meine Frage ist, ob es sich rentiert, generierte Grafiken (Größenordnung <= 64px*64px,8bit; 0.1~3kB) am Server zwischenzuspeichern?

Könnte es nicht u. U. performanter sein, die Grafiken einfach inline zu schicken? Ich habe nun wirklich keine Ahnung, wie gut GD implementiert ist und welche Latenzen File-System-Zugriffe erzeugen.

Der Hintergrund ist, dass der geneigte Surfer Parameter ändern kann, falls ihm das Default-Set zu aufdringlich ist (z. B. auf kleinerem Bildschirm).

Pro Dokument sind übrigens zw. sechs und zwölf Grafiken involviert... naja, das könnten auch mehr werden...

Mal egal... hat da irngwer irngwelche Erfahrungswerte? Oder wie kann ich mir von PHP anzeigen lassen, wie lange die Generierung eines Dokuments gebraucht hat? Erste Versuche mit date('u') liefern grundsätzlich Nullzeit... da läuft wohl was schief...

Danke vielmals...

[Der Martin]

Hallo,

Also, meine Frage ist, ob es sich rentiert, generierte Grafiken (Größenordnung <= 64px*64px,8bit; 0.1~3kB) am Server zwischenzuspeichern?

das hängt natürlich sehr davon ab, wie oft diese Grafiken in immer derselben Form abgerufen werden. Wenn man mal überlegt, was die GD-Lib so alles an Aufwand treiben muss, und dass das Lesen der Originaldatei ja vermutlich auch schon ein Teil davon ist, dann ist das dynamische Generieren von Grafiken sicher um ein Vielfaches aufwendiger. Aber wenn die Ressource dann nur alle zwei Stunden mal abgerufen wird, so what? Wenn es dagegen um mehrere tausend Requests pro Stunde geht, sieht das schon wieder anders aus - dann lohnt es sich sicher, die einmal generierten Grafiken als Datei abzulegen und bei Folgerequests erstmal nachzusehen, ob's die gewünschte Variante schon gibt.

Könnte es nicht u. U. performanter sein, die Grafiken einfach inline zu schicken?

Ob inline oder nicht, hat nichts mit der Performance zu tun - es sei denn, ich verstehe dich gerade völlig falsch.

Erste Versuche mit date('u') liefern grundsätzlich Nullzeit... da läuft wohl was schief...

Hast du denn PHP 5.2.2 oder höher? Andernfalls wäre eventuell microtime() eine Alternative.

Ciao,
 Martin

[&69lig;]

das hängt natürlich sehr davon ab, wie oft diese Grafiken in immer derselben Form abgerufen werden.

Das Default-Set wird natürlich als Datei(en) vorgehalten.

Wenn man mal überlegt, was die GD-Lib so alles an Aufwand treiben muss,

Das weiß ich ja eben nicht... :-/

und dass das Lesen der Originaldatei ja vermutlich auch schon ein Teil davon ist,

Eine Originaldatei in diesem Sinne gibt es nicht. Alles von Grund auf mit GD...

dann ist das dynamische Generieren von Grafiken sicher um ein Vielfaches aufwendiger.

Es ist nur ein Shade hier, ein Blend da, ein bisschen Text... keine Photobearbeitung oder etwas, was auch nur halbwegs in die Richtung ginge...

[...] - dann lohnt es sich sicher, die einmal generierten Grafiken als Datei abzulegen und bei Folgerequests erstmal nachzusehen, ob's die gewünschte Variante schon gibt.

Ja, sollte auch kein Hexenwerk sein, überflüssige Varianten nach ein paar Std. zu löschen...

Könnte es nicht u. U. performanter sein, die Grafiken einfach inline zu schicken?

Ob inline oder nicht, hat nichts mit der Performance zu tun - es sei denn, ich verstehe dich gerade völlig falsch.

Naja, wenn ich für die Dateien (außer den Defaults) überhaupt keinen Filesystem-Zugriff benutze, scheint mir das scho... okay... sagen wir mal, es verhindert Latenzen... sonst müsste ich ja Datei speichern, die URL schicken; der Client liest die URL und fragt sie an; der Server muss die Datei wieder laden (FS-Cache mal hin oder oder...) und dann schicken...

Erste Versuche mit date('u') liefern grundsätzlich Nullzeit... da läuft wohl was schief...

Hast du denn PHP 5.2.2 oder höher? Andernfalls wäre eventuell microtime() eine Alternative.

php 5.3.3, zend 2.3.0

Ich werde mir die Seite mal anschauen... danke!

[Der Martin]

Hi,

Wenn man mal überlegt, was die GD-Lib so alles an Aufwand treiben muss,
Das weiß ich ja eben nicht... :-/

nein, aber man kann es anhand der notwendigen Schritte erahnen. Wenn es eine Grafikdatei gibt, die quasi die Vorlage ist, muss die erst gelesen und dekomprimiert werden, dann kommen die Änderungen, und schließlich muss aus der unkomprimierten Bitmap-Grafik im Arbeitsspeicher wieder eine komprimierte JPEG- oder PNG-Ressource werden. Dass das mehr Aufwand ist, als eben mal nachzuprüfen, ob eine bestimmte Datei existiert, und diese ggf. 1:1 an den Client durchzureichen, ist logisch.

und dass das Lesen der Originaldatei ja vermutlich auch schon ein Teil davon ist,
Eine Originaldatei in diesem Sinne gibt es nicht. Alles von Grund auf mit GD...

Dann ist das möglicherweise schon eine Performance-Sünde. Aber ich weiß nicht, wie die Grafik aussieht; vielleicht ist sie tatsächlich so einfach zu generieren, dass sich eine Vorlage nicht lohnt.

Es ist nur ein Shade hier, ein Blend da, ein bisschen Text... keine Photobearbeitung oder etwas, was auch nur halbwegs in die Richtung ginge...

Egal, das ist aufwendig genug, wenn du bedenkst, dass man da jedes Pixel einzeln anfassen muss.

Ob inline oder nicht, hat nichts mit der Performance zu tun - es sei denn, ich verstehe dich gerade völlig falsch.
Naja, wenn ich für die Dateien (außer den Defaults) überhaupt keinen Filesystem-Zugriff benutze, scheint mir das scho... okay... sagen wir mal, es verhindert Latenzen...

Dann verabschiedest du dich aber bewusst von der ersten Caching-Ebene.

sonst müsste ich ja Datei speichern, die URL schicken; der Client liest die URL und fragt sie an; der Server muss die Datei wieder laden (FS-Cache mal hin oder oder...) und dann schicken...

Unfug. Das geht alles in einem Aufwasch:
 * Request geht an den Server
 * Server schmeißt PHP an
 * PHP sieht nach, ob die Datei schon existiert
 * falls ja: An Client senden und fertig
 * Grafik anhand der Parameter erzeugen
 * Grafik in Datei speichern (Caching für Folgerequests)
 * Grafik als HTTP-Ressource ausliefern

So long,
 Martin

[ChrisB]

Hi,

Unfug. Das geht alles in einem Aufwasch:
* Request geht an den Server
* Server schmeißt PHP an
* PHP sieht nach, ob die Datei schon existiert

Oder 2 und 3 vertauschen, und bei ehemals-3-jetzt-2 „PHP“ durch „Server“ ersetzen.

MfG ChrisB

[ChrisB]

Hi,

Also, meine Frage ist, ob es sich rentiert, generierte Grafiken (Größenordnung <= 64px*64px,8bit; 0.1~3kB) am Server zwischenzuspeichern?

Kommt drauf an™.

Könnte es nicht u. U. performanter sein, die Grafiken einfach inline zu schicken? Ich habe nun wirklich keine Ahnung, wie gut GD implementiert ist und welche Latenzen File-System-Zugriffe erzeugen.

Was hat der Transport der Daten zum Client mit der serverseitigen Erzeugung dieser Daten zu tun?

Der Hintergrund ist, dass der geneigte Surfer Parameter ändern kann, falls ihm das Default-Set zu aufdringlich ist (z. B. auf kleinerem Bildschirm).

Kann er aus bestimmten Vorgaben wählen, oder Werte frei wählen?
Und um was für Parameter geht es?

Pro Dokument sind übrigens zw. sechs und zwölf Grafiken involviert... naja, das könnten auch mehr werden...

Handelt es sich um echte Bilder, die Informationen transportieren, oder um Hintergrundgrafiken, die lediglich Verzierung darstellen?

Mal egal... hat da irngwer irngwelche Erfahrungswerte?

Ja. Dass unspezifische Fragestellungen keine konkreten Antworten erlauben, hat die Erfahrung längst gezeigt :-)

Oder wie kann ich mir von PHP anzeigen lassen, wie lange die Generierung eines Dokuments gebraucht hat? Erste Versuche mit date('u') liefern grundsätzlich Nullzeit... da läuft wohl was schief...

microtime

Stelle aber sicher, dass du auch das „richtige“ misst, wenn du daraus sinnvolle Schlüsse ziehen willst.

MfG ChrisB

[&69lig;]

Was hat der Transport der Daten zum Client mit der serverseitigen Erzeugung dieser Daten zu tun?

Als Surfer sehe ich einen Teil der Performanz eines Webauftritts in der Zeit, die zwischen Request und Anzeige eines Dokuments verstreicht, also auch inkl. einiger möglicher Verzögerungen, auf die der Betreiber gar keinen Einfluss hat (Routing etc.). Klar, dass man als Web-Autor einen anderen Blick darauf hat/haben sollte, aber ich versuche, beide Seiten zu sehen...

Kann er aus bestimmten Vorgaben wählen, oder Werte frei wählen?
Und um was für Parameter geht es?

Er kann aus bestimmten Vorgaben frei wählen :-) Nein, er kann schon frei wählen, aber die Parameter werden z. T. normalisiert, um solche, die weniger Sinn machen, zu vermeiden...

Handelt es sich um echte Bilder, die Informationen transportieren, oder um Hintergrundgrafiken, die lediglich Verzierung darstellen?

Es geht mehr um den Look...

Ja. Dass unspezifische Fragestellungen keine konkreten Antworten erlauben, hat die Erfahrung längst gezeigt :-)

Naja...

microtime

Auch dir danke!

Stelle aber sicher, dass du auch das „richtige“ misst, wenn du daraus sinnvolle Schlüsse ziehen willst.

Jau, pack ich schon... ;-)

[ChrisB]

Hi,

Was hat der Transport der Daten zum Client mit der serverseitigen Erzeugung dieser Daten zu tun?

Als Surfer sehe ich einen Teil der Performanz eines Webauftritts in der Zeit, die zwischen Request und Anzeige eines Dokuments verstreicht, also auch inkl. einiger möglicher Verzögerungen, auf die der Betreiber gar keinen Einfluss hat (Routing etc.).

Ich hatte eigentlich eine Antwort auf meine Rückfrage erwartet ...

Erst wirst du inline-Auslieferung von Bilddaten und deren Erzeugung in einen Topf - unsinnigerweise - und jetzt schüttest du auch noch den ominösen Faktor Routing in die Suppe.

Handelt es sich um echte Bilder, die Informationen transportieren, oder um Hintergrundgrafiken, die lediglich Verzierung darstellen?

Es geht mehr um den Look...

Dann wäre zu überlegen, ob die Verwendung von CSS Sprites in Betracht kommt.

MfG ChrisB

[&69lig;]

Was hat der Transport der Daten zum Client mit der serverseitigen Erzeugung dieser Daten zu tun?

Als Surfer sehe ich einen Teil der Performanz eines Webauftritts in der Zeit, die zwischen Request und Anzeige eines Dokuments verstreicht, also auch inkl. einiger möglicher Verzögerungen, auf die der Betreiber gar keinen Einfluss hat (Routing etc.).

Ich hatte eigentlich eine Antwort auf meine Rückfrage erwartet ...

Wenn du nur das liest, was du lesen willst, wirst du nie eine Antwort finden, die dich zufrieden stellt. (Das kling jetzt etwas kontradiktiv, aber...) Sieh's einfach mal im Kontext...

Erst wirst du inline-Auslieferung von Bilddaten und deren Erzeugung in einen Topf - unsinnigerweise -

So unsinnig ist das gar nicht... jemand fragt www.example.com/index.php?p1=some&p2=thing an...

In der Datei wird dann geprüft, ob p1 und p2 den Defaults entsprechen (oder überhaupt angegeben sind). Dann wird ggf. die Grafik generiert. Jetzt habe ich die Möglichkeit, die generierte (oder die gelesene) Grafik per Data-Url inline zu schicken, oder aber ich schicke nur den URL der Datei... Das sind (Überlegungen zu den) Möglichkeiten, die Grafik zum Client zu schaffen und die passen allesamt in diesen (kleinen) Topf.

Und wenn ich da jetzt eine ganz fabulöse Vorgehensweise übersehen haben oder schlicht und ergreifend noch nicht kennen sollte, darfst du sie mir gerne um die Ohren hauen, aber Polemik hilft hier außer deinem stress relief niemandem, und dem auch nur temporär, glaubs mir...

und jetzt schüttest du auch noch den ominösen Faktor Routing in die Suppe.

Schalte doch mal dein(en) Modem/Router/AP ab und schau, wie schnell du dann noch zu diesem Forum verbindest... Ich hätte auch DNS sagen können... es spielt halt vieles mit rein, was mit HTML oder PHP erstrangig gar nichts zu tun hat... BTW, was ist an Routing ominös?

Aber wenn wir schon bei Suppe sind: Auch die besten Nudeln machen ohne Fleisch und Gemüse keine Nudelsuppe...

Dann wäre zu überlegen, ob die Verwendung von CSS Sprites in Betracht kommt.

Habe ich bis vor einigen Minuten noch gar nicht gekannt... Was ich bis jetzt drüber gesehen habe, sagt mir, dass es hier nicht passt, aber ist vielleicht später mal ein gutes "Rezept" :-)

[ChrisB]

Hi,

In der Datei wird dann geprüft, ob p1 und p2 den Defaults entsprechen (oder überhaupt angegeben sind). Dann wird ggf. die Grafik generiert. Jetzt habe ich die Möglichkeit, die generierte (oder die gelesene) Grafik per Data-Url inline zu schicken, oder aber ich schicke nur den URL der Datei...

Ja, schön.
Hat aber beides nichts damit zu tun, ob du die Grafik serverseitig on-the-fly erstellst, oder aus einer Datei liest.

Das sind (Überlegungen zu den) Möglichkeiten, die Grafik zum Client zu schaffen und die passen allesamt in diesen (kleinen) Topf.

Und der Topf, in dem dir Erzeugung der Grafikdaten drin rumschwimmt, ist und bleibt ein anderer.

Schalte doch mal dein(en) Modem/Router/AP ab und schau, wie schnell du dann noch zu diesem Forum verbindest... Ich hätte auch DNS sagen können... es spielt halt vieles mit rein, was mit HTML oder PHP erstrangig gar nichts zu tun hat...

Auch das spielt in die Erzeugung der Grafik kein bisschen mit rein.

BTW, was ist an Routing ominös?

Dass du diesen Begriff in den gleichen Topf wie alles andere wirfst, ist ominös.

MfG ChrisB

[&69lig;]

Hi,

In der Datei wird dann geprüft, ob p1 und p2 den Defaults entsprechen (oder überhaupt angegeben sind). Dann wird ggf. die Grafik generiert. Jetzt habe ich die Möglichkeit, die generierte (oder die gelesene) Grafik per Data-Url inline zu schicken, oder aber ich schicke nur den URL der Datei...

Ja, schön.
Hat aber beides nichts damit zu tun, ob du die Grafik serverseitig on-the-fly erstellst, oder aus einer Datei liest.

Es ging um die Möglichkeiten... Wie gesagt: Kontext beachten...

Das sind (Überlegungen zu den) Möglichkeiten, die Grafik zum Client zu schaffen und die passen allesamt in diesen (kleinen) Topf.

Und der Topf, in dem dir Erzeugung der Grafikdaten drin rumschwimmt, ist und bleibt ein anderer.

Ich kann eine nicht vorhandene Grafik nicht zum Client schaffen, also gehört die ggf. erforderliche Erzeugung dazu... Es ging darüberhinaus ursprünglich um die Frage, ob ich die Grafiken überhaupt speichere; wenn nicht, gehörte (Konjunktiv ;-) die Erzeugung grundsätzlich dazu.

Schalte doch mal dein(en) Modem/Router/AP ab und schau, wie schnell du dann noch zu diesem Forum verbindest... Ich hätte auch DNS sagen können... es spielt halt vieles mit rein, was mit HTML oder PHP erstrangig gar nichts zu tun hat...

Auch das spielt in die Erzeugung der Grafik kein bisschen mit rein.

Wenn ich die Grafik nicht über's Netz schicken kann, brauche ich sie gar nicht erst erzeugen... (Mal abgesehen davon, dass ich's eh normalerweise nicht machen würde, weil der Request nicht ankommt.)

BTW, was ist an Routing ominös?

Dass du diesen Begriff in den gleichen Topf wie alles andere wirfst, ist ominös.

<repo>
Dann beschwer dich bitte nicht, wenn ich mich mal nicht ganz eindeutig ausdrücke, denn "ominöses Routing" ist nicht nicht eindeutig.
</repo>

[hotti]

hi,

Also, meine Frage ist, ob es sich rentiert, generierte Grafiken (Größenordnung <= 64px*64px,8bit; 0.1~3kB) am Server zwischenzuspeichern?

Das Ganze mal praktisch durchzutesten (benchmark) ist eine interessante Studie, die ich mir nicht entgehen lassen würde.

Hotti