mmofacts.com

Bilder-Request

gepostet vor 17 Jahre, 8 Monate von riki1512
Servus,
ich fordere in einem Request 120 kleine Bilder an (jedes Bild max. 1KB), die Bilder werden via php gd generiert. Wie glaubt ihr verhält es sich mit der Performance, wenn ich stattdessen nur 30 Bilder, dafür jedes bis zu 4KB groß (also jeweils 4 zusammengesetzt), anfordere ? Glaubt ihr, ich hätte clientseitig viel gewonnen und würde auch den Server ziemlich entlasten ? Könnte das natürlich auch versuchsweise hincoden um mal zu sehen, wieviel das bringt, bin aber bei der Arbeit und es interessiert mich gerade. Was glaubt ihr, so rein intuitiv (oder wissend) ?
Oftmals aber muss ich aber auch nur sehr wenige Bilder anfordern, dann hätte ich halt den Nachteil, dass der Request hier dann 4 mal so große Daten anfordert, aber alls halt immer noch im Bereich weniger KB. Ist ja nicht die Welt, weshalb sich mir halt die Frage stellt, ob sich das Summa Summarum lohnt.
gepostet vor 17 Jahre, 8 Monate von Kampfhoernchen
Da hilft nur ausprobieren.
Sinnvoll wär hier auf jeden Fall ein Cache, da Bilder-Berechnen nicht unbedingt hochperformant ist.
gepostet vor 17 Jahre, 8 Monate von raufaser
Dem kann ich nur zustimmen. Die GD verbraucht schon einiges an CPU Zeit, da ist der Traffik der Bilder gar nicht mal unbedingt das Problem.
Grundlegend lässt sich allerdings sagen: Je mehr Bilder, umso mehr Overhead (=traffic), weil ja jedes einzelne Bild einen IMG Header hat.
Eine Alternative könnte übrigens sein, wenn du die Bilder nicht direkt berechnest, sondern die einzelnen Elemente der Bilder als statische Grafiken mit Transparenz anlegst und diese dann mit Layern übereinanderstapelst. Dann hast du zwar mehr Traffic, weil es mehr Bilder sind, logisch, aber du wirst weniger Probleme mit der CPU Auslastung bekommen und die sind bei massivem GDlib Einsatz wohl kaum zu vermeiden. Obwohl: Mehr Traffic bleibt da noch fraglich, statische Bilder werden ja gecached. Onthefly generierte Bilder werden jedes Mal übertragen. Könnte also durchaus sein, dass du mit statischen Bilder im Endeffekt sogar noch Traffic schonst, durch den Browsercache.
Das mit den Layern mache ich bei meinem BG übrigens auch so und ich bin damit sehr zufrieden. So kann es z.B. auch Objekte unter und über der Spielfigur geben, (css: z-index) ohne den Einsatz der GDlib.
Ich hoffe das konnte dir zumindest ein wenig helfen.
Gruß,
Marc
gepostet vor 17 Jahre, 8 Monate von knalli
Image/CSS Slicing war doch das Verfahren, wo man mehrere Bilder in einem verpackt und per geeigneter CSS-Anwahl immer nur einen Auschnitt anspricht. Das wäre zB etwas für Navigationspunkte (wie oben in GN vom Forum). Statt 5-6 Requests brauchts nur einen Request, die Datei ist zudem maximal 5-6x so groß.
Bei sehr kleinen Dateien machen sich Requests bemerkbar.. kommt aber auch drauf an, wie viele Dateien es sind und wie viele Zugriffe es auf die Datei gibt.
gepostet vor 17 Jahre, 8 Monate von schokofreak
Hmmm... Knalli: Bist du dir da so sicher?
Ich bin in einer Web-Welt aufgewachsen wo bilder gesplittet wurden... um Ladezeit einzusparen. Und diese Grundgsetze gelten meines Wissens immer noch.
Gruss
gepostet vor 17 Jahre, 8 Monate von Frostbringer
Und ich bin in einer Welt aufgewachsen, wo man Programme die nachweislich nichts getan haben genutzt hat, um den RAM zu vergrößern. Und jeder hat darauf geschworen. (DOS-Zeiten)
Aber bei sehr kleinen Datein spielt der Overhead garantiert eine Rolle. Gedoch bin ich skeptisch, ob die Lösund mit dem "CSS-Slicing" nicht mehr Ärger als Nutzen bringt. Habe jedenfalls schon schlechte Erfahrungen damit gemacht, Aufgaben an den Clienten zu delegieren. Weil es ist einfach ein gewaltiger Aufwand zu testen, ob es auch so funktioniert wie man es sich vorstellt. Und das nächste Update des Webbrowsers macht einen vielleicht alles wieder zunichte.
edit: Bin gerade hingewiesen worden, dass dies wegen der komprimierten Übertragung angeblich heutzutage doch keinen Unterschied machen soll. Gepaart mir einer langatmigen Erklärung, der ich nicht richtig zugehört habe. Naja, wie auch immer. Wahrscheinlich liegen wir eh alle falsch. Es wird sich wohl oder übel mal jemand hinsetzen müssen, um es auszuprobieren.
edit2: Kampf den Rechtschreibfehlern!
gepostet vor 17 Jahre, 8 Monate von knalli
Original von schokofreak
Hmmm... Knalli: Bist du dir da so sicher?
Ich bin in einer Web-Welt aufgewachsen wo bilder gesplittet wurden... um Ladezeit einzusparen. Und diese Grundgsetze gelten meines Wissens immer noch.
Gruss

Ich hab es selber auch noch nicht angewendet, es kommt drauf an.
Ich denke, dieser Link würde mit CSS-Slicing viel schneller geladen.
gepostet vor 17 Jahre, 8 Monate von riki1512
Wow, der Link lädt echt lange. Das meinte ich eben. Wenn hier jeweils 4 in einem Bild zusammengefasst wären, würde das mit Sicherheit schneller gehen (oder gar noch schneller wenn im Extremfall alle auf einem Bild zusammengefasst wären). Ein Request sind halt nicht nur die Daten und die TCP/IP+HTTP-Verpackung (die sich auch nach Anzahl der Requests vergrößert aber dennoch recht klein ist), sondern auch der Request über den Socket, das initialisieren eines Kindprozesses im Webserver, der den Request beantwortet, und das Schicken der Antwortdaten (über den Socket). In meinem Fall muss auch noch jedes mal die PHP-Klasse initialisiert und instantiiert werden, die das Image generiert. Wenn das alles seltener geschieht, macht sich das halt bemerkbar, auch wenn in gd immer die gleiche Anzahl an Pixeln prozessiert wird. Ich werde bei obigem Beispiel übrigens den Verdacht nicht los, dass mein Browser den Request für das Bild n erst startet, wenn die Antwort für das Bild n-1 angekommen ist, wahrscheinlich täuscht dies aber nur.
An der reinen PHP-Rechenzeit kann ich übrigens nicht schrauben, die ist immer gleich, da ich nichts doppelt zeichne. Wenn ich je 4 Bilder zusammentun würde, würde ich exakt viermal so viel zeichnen, wie bei einem kleinen Bild. Die GD-Zeit ist bei mir auch nicht so tragisch, da die Bilder sehr simpel sind (einfache Pixel-Art im Rahmen meiner grafischen Talente).
Tja, werde den Unterschied wohl mal ausprobieren und auch stoppen müssen.
gepostet vor 17 Jahre, 8 Monate von riki1512
Habe das ganze nun mal bei einem Hoster ausprobiert, braucht gar nicht programmtechnisch exakt festgehalten zu werden, mit etwa 4-5 mal weniger, dafür 4-5 mal so großen Bildern ist es um ein vielfaches schneller. Bei 120 Bildern ist es erschreckend lahm. Mann, dass der Unterschied so groß ist, hätte ich nicht gedacht. Hatte das lokal nicht bemerkt, weil da immer alles so gut wie "gleich da" ist. Da der Nachteil in meinem Fall jetzt klar überwiegt, werde ich das ganze umcoden müssen.
Bei 120 Bildern lädt der Browser wirklich brav in der Reihenfolge, in der die Bilder im Quellcode vorkommen, eines nach dem anderen - und das dauert. Weshalb das feuern so vieler Requests so lange dauert, bzw. die Antworten so lange auf sich warten lassen, mag dann womöglich tatsächlich an den oben genannten "Randerscheinungen" liegen (TCP/IP+HTTP Verpackungen, mehr Netzsendungen, Kindprozesse im Webserver, PHP-Initialisierungen...).
gepostet vor 17 Jahre, 8 Monate von knalli
Das liegt auch an dem Browser.. hilft jetzt nicht beim Problem, aber als kleine Anmerkung.
gepostet vor 17 Jahre, 8 Monate von TheUndeadable
> Weshalb das feuern so vieler Requests so lange dauert
Laut RFC sind nur zwei gleichzeitige HTTP-Verbindungen zu einem Server erwünscht bzw erlaubt.
Der IE und der FF halten sich zumindest an die RFC. Über die Registry bzw about:config kann man dieses Verhalten modifizieren...
gepostet vor 17 Jahre, 8 Monate von Klaus
Wenn Pipelining aktiviert wird, gehen auch mehrere parallele Requests durch. Aber warum nicht gleich ein großes Bild rendern?
gepostet vor 17 Jahre, 8 Monate von riki1512
Original von Klaus
Wenn Pipelining aktiviert wird, gehen auch mehrere parallele Requests durch. Aber warum nicht gleich ein großes Bild rendern?

Weil ich oftmals nur einzelne Teile des ganzen aktualisieren muss, da möchte ich nicht jedesmal ein großes Gesamtbild neu rendern.
gepostet vor 17 Jahre, 8 Monate von riki1512
Hab das ganze übrigens gelöst. Base64 kodierte Bilder lautet das Zauberwort, eigentlich ziemlich simpel, dass ich da nicht früher drauf gekommen bin...
Musste doch nichts umcoden (bis auf die paar Stellen zum generieren und einbinden in base64).

Auf diese Diskussion antworten