nicht angemeldet
gesprengte Bandwidth
Hallo,
Könnt Ihr mir vielleicht ein paar Infos dazu geben:
ein Freund hat das Problem, dermaßen viele Zugriffe auf seiner Homepage zu haben, daß die Bandwidth überschritten wird (was Zusatzkosten bedeutet). Die HTML-Seiten sind ursprünglich mit Frontpage geschrieben, das an vielen-vielen Stellen viele-viele unnötige Formatierungsanweisungen einfügt, was dem HTML-Dokument zu ungeahnter Größe verhilft. Spaß beiseite: Ich habe die Seiten nun einmal mittels CSS formatiert (dabei versucht XHTML-Strukturen zu verwenden, was aber aufgrund der leider nötigen NN4-kompatibilität nur eingeschränkt gelang).
Die neuen HTML-Dateien (mit 'embedded-CSS') sind natürlich größer als die alten Dateien. Selbverständlich werde ich eine externe CSS-Datei verwenden, wodurch die HTML-Dateien selbst kleiner werden als die alten.
Nun zu meiner Frage: Die externe CSS-Datei muß beim ersten Zugriff auf eine Seite vom Server geladen werden - klar, aber wie sieht es bei Folgeseiten aus. Ausgehend vom Normalfall, daß ein Cache verwendet wird: soweit ich weiß überprüfen Browser<->Server, ob sich die Datei inzwischen verändert hat und lädt sie nicht, wenn... und hier ist mir unklar wie die Überprüfung stattfindet. "Nur" via Timestamp und filesize?
Mit anderen Worten: spart man Bandwidth ein?
Hoffentlich ist die Frage halbwegs verständlich formuliert.
Vielen Dank im Voraus
Manfred
-
Hi!
Mit anderen Worten: spart man Bandwidth ein?
Normalerweise ja, wenn der Webserver korrkt konfiguriert ist.
Grüße
Andreas-
Hallo,
Danke für die Info!
Inzwischen ist mir noch 'was eingefallen: Da die Seiten generiert werden, würde es doch auch ein bißchen 'was bringen, zumindest alle leading blanks und vielleicht auch Zeilenumbrüche zu entfernen - oder?
Manfred
-
Hi Manfred,
Inzwischen ist mir noch 'was eingefallen: Da die Seiten generiert werden, würde es doch auch ein bißchen 'was bringen, zumindest alle leading blanks und vielleicht auch Zeilenumbrüche zu entfernen - oder?
Im Prinzip ja.
Was es aber wirklich bringt ist Kompression. (Fast)Alle Browser können komprimierten Inhalt empfangen und das bringt dann 70% und nicht 7%(*).unter:
http://www.google.com/search?hl=de&ie=UTF-8&oe=utf-8&q=site%3Ateamone.de+mod_gzip&btnG=Google-Suche&lr=
<site:teamone.de gzip content negotiation>
solltest du eigentlich was passendes zum weitersuchen finden.Gruss,
Carsten(*)Zahlen frei geraten, aber die Grössenordnung kommt hin.
-
Hallo,
Vielen Dank für Eure Tips!
Bis dann
Manfred
-
-
-
-
Hallo Manfred!
Wenn der wirklich nur mit HTML-Seiten so viel traffic hinbekommt, dass irgendeine volume-Beschränkungen greifen heist das
- entweder ist das Volumen sehr mikrig
- hat der supertolle Seiten, dann würde ich die aber auf einem Server mit viel traffic hosten (lassen)
oder, was mir fast plausibler erscheint, es ist gar nicht das ASCII-Zeugs, sondern Bilder oder andere Daten, die das verursachen. Was ist das für eine Seite und von wieviel traffic redest du da? Has du mal gecheckt, ob vielleicht Bilder erst im Browser "zurechtgezoomt" werden?
Clemens
-
Hallo,
oder, was mir fast plausibler erscheint, es ist gar nicht das ASCII-Zeugs, sondern Bilder oder andere Daten, die das verursachen. Was ist das für eine Seite und von wieviel traffic redest du da? Has du mal gecheckt, ob vielleicht Bilder erst im Browser "zurechtgezoomt" werden?
die überschrittene Grenze sind 15gb.
Natürlich sind da auch viele Bilder dabei, aber da kann ich den Hebel nicht ansetzen, denn die Bilder sind in Qualität und Filegröße optimal ( die Site ist übrigens http://www.automobile-riekmann.com )
Darum versuche ich eben durch Einsatz modernerer HTML-Technik (eben auch mit Hilfe von CSS) zumindest die (von Frontpage aufgeblasenen) Seiten zu verkleinern.Manfred
-
Hallo!
die überschrittene Grenze sind 15gb.
Natürlich sind da auch viele Bilder dabei, aber da kann ich den Hebel nicht ansetzen, denn die Bilder sind in Qualität und Filegröße optimal ( die Site ist übrigens http://www.automobile-riekmann.com )
Darum versuche ich eben durch Einsatz modernerer HTML-Technik (eben auch mit Hilfe von CSS) zumindest die (von Frontpage aufgeblasenen) Seiten zu verkleinern.Dir ist bewußt, das _jeder_ Besucher, der auf diese eigentliche Startseite(news) will _weit_über_ 0,5 MB von Eurem Server läd? Bedenke - der Besucher war bis hierher _nur_ auf der Startseite(news), d.h. dieses Vergnügen haben _alle_ Leute, auch die die da eigentlich nicht hinwollten...
Mit den hier genannten Komprimierungsmethoden kannst Du nur den HTML-Code Anteil reduzieren, der aber gerademal gut 15% ausmacht. D.h. Du sparst hier vielleicht 60-70 KB.
Auf der news-Seite hast Du alleine fast 40 Bilder, davon sind 16 über 10 KB, und 2 knapp 40 KB. Da ist _sicher_ noch was zu komprimieren, probiers mal mit Photoshop!Das müßtest Du aber auch in Deinen Logfiles schön sehen, wo besonders viel Traffic entsteht, welche Dateien am meisten geladen werden...
Rechne mal nach, das große Problem sind die vielen Bilder, die Du vielleicht mit Photoshop noch ein wenig verkleinern kannst,aber auch nicht viel, mehr geht nicht. Es sind schlichtweg zu viele! Die Struktur ist IMHO völlig falsch. Die Startseite braucht kein Mensch, die "newsseite" ist die eigentliche Startseite, und dafür ist sie _viel_ zu umfangreich. Ich würde die news erheblich kürzen, deren Anzahl und auch deren jeweilige Länge. Lieber die aktuellsten news, und dann Verweise auf weitere Seite(n).
Und gehe überhaupt etwas sparsamer mit Bildern um, verwende auf alle Fälle gzip-Komprimierung, wie auch immer sich das bei Dir umsetzen läßt.
Verwende entsprechende HTTP-Header um möglichst alle Beteiligten zum Caching anzuregen.
Viele Grüße
Andreas
-
-
Nun zu meiner Frage: Die externe CSS-Datei muß beim ersten Zugriff auf eine Seite vom Server geladen werden - klar, aber wie sieht es bei Folgeseiten aus. Ausgehend vom Normalfall, daß ein Cache verwendet wird: soweit ich weiß überprüfen Browser<->Server, ob sich die Datei inzwischen verändert hat und lädt sie nicht, wenn... und hier ist mir unklar wie die Überprüfung stattfindet. "Nur" via Timestamp und filesize?
Über das Datum, dazu gibt es die Last-Modified bzw. If-Modified-Since-Angabe (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.29).
Du kannst übrigens auch noch diese Überprüfungen einsparen, indem Du ein Verfallsdatum setzt, zum Beispiel mit mod_expires (http://httpd.apache.org/docs/mod/mod_expires.html). Einsparungspotential auf meinen Seiten im Falle von .html und .shtml-Sachen: 15% bis 20%. Grafiken habe ich noch nicht geprüft.
Gruß,
soenk.e-
Hi!
Du kannst übrigens auch noch diese Überprüfungen einsparen, indem Du ein Verfallsdatum setzt, zum Beispiel mit mod_expires (http://httpd.apache.org/docs/mod/mod_expires.html). Einsparungspotential auf meinen Seiten im Falle von .html und .shtml-Sachen: 15% bis 20%. Grafiken habe ich noch nicht geprüft.
15% bis 20% was? Äpfel? Birnen? ;-)
Vermutlich Requestst, oder sogar KB?Grüße
Andreas-
Du kannst übrigens auch noch diese Überprüfungen einsparen, indem Du ein Verfallsdatum setzt, zum Beispiel mit mod_expires (http://httpd.apache.org/docs/mod/mod_expires.html). Einsparungspotential auf meinen Seiten im Falle von .html und .shtml-Sachen: 15% bis 20%. Grafiken habe ich noch nicht geprüft.
15% bis 20% was? Äpfel? Birnen? ;-)
Vermutlich Requestst, oder sogar KB?Bananen :) Nein, es handelt sich um das, was der Webalizer als "Seiten" bezeichnet. Das ist natürlich nicht sonderlich genau oder verlässlich, aber der Anstieg der Seitenabrufe (mit ausgeschaltetem Verfallsdatum) war gegenüber den Zuwächsen bei KByte oder Besuchen durchaus zu erkennen.
Es sollte vielleicht auch erwähnt werden, daß diese Einsparungen prinzipbedingt relativ zunehmen, je mehr Verkehr insgesamt anliegt. Wenn der Verfallszeitraum kürzer ist als die durchschnittliche Besuchshäufigkeit ist die Angabe des Verfallsdatums logischerweise wenig effektiv.Gruß,
soenk.e-
Hi Sönke,
15% bis 20% was? Äpfel? Birnen? ;-)
Vermutlich Requestst, oder sogar KB?ich hätte auch "Requests" getippt, denn ich habe ähnliche Erfahrungswerte.
(kBytes natürlich nicht, weil man dabei nur die klassischen 0-Byte-HTTP-304-Requests spart.)Das hängt allerdings davon ab, wie gut oder schlecht die Browser eingestellt sind.
Manchen Anwendern muß man halt erst erklären, was die Caching-Strategien in der Konfiguration ihres Browsers bewirken und wieso "Automatisch" bzw. "when the page is out of date" die beste Einstellung ist.Bananen :) Nein, es handelt sich um das, was der Webalizer als "Seiten" bezeichnet.
Und was genau ist das bei Dir? Denn Du definierst das, in der Webalizer-Konfiguration ...
---------------------------------------------------------------------
Endungen von zu zählenden "Seiten"
PageType layout
PageType htm
PageType html
PageType shtml
PageType pl(.html sind bei uns nur 'Verpackung': Framesets, hidden frames etc.)
---------------------------------------------------------------------
Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.-
Bananen :) Nein, es handelt sich um das, was der Webalizer als "Seiten" bezeichnet.
Und was genau ist das bei Dir? Denn Du definierst das, in der Webalizer-Konfiguration ...
Nein, denn auf die Konfiguration meines Hosters habe ich keinen Zugriff und selbst installieren und dafür jeden Monat 130 MByte access_log runterzuladen, habe ich keine Lust.
Davon abgesehen ist mir der Webalizer eh etwas unsympatisch, da er Seiten dummerweise nur anhand der Dateiendung erkennen kann (AFAIK) und nicht am Inhaltstyp - ein kleines Problem, wenn man URLs grundsätzlich ohne Endung angibt (allerdings hält sich die Anzahl an Grafik-URLs ohne Endung eben wegen dieser Einschränkung in engen Grenzen).
Und selbst wenn es möglich sein sollte, "Seiten" an Hand des Typs zu erkennen, bringt mir das auch nichts, da ich auch keinen Zugriff auf die Webserverkonfiguration habe, um das Protokollformat um Content-Type zu erweitern.Gruß,
soenk.e-
Hi Sönke,
Und was genau ist das bei Dir? Denn Du definierst das, in der Webalizer-Konfiguration ...
Nein, denn auf die Konfiguration meines Hosters habe ich keinen Zugriffich auch nicht.
und selbst installieren und dafür jeden Monat 130 MByte access_log runterzuladen, habe ich keine Lust.
Ich habe mir einen eigenen Webalizer auf dem Server meines Hosters installiert (das ist ja nur ein binary plus eine Konfigurationsdatei) und werte meine Logs dort aus. Ich muß die Logs also nicht übertragen.
Und das Binary habe ich auch nur deshalb hochgespielt, weil mein Provider noch Webalizer 1.3 verwendet und ich Webalizer 2.0 genommen habe. Ansonsten hätte ich auch den bereits installierten Webalizer aufrufen und diesem als Kommandozeilen-Parameter den Pfadnamen meiner eigenen Konfigurationsdatei übergeben können.
Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.-
Ich habe mir einen eigenen Webalizer auf dem Server meines Hosters installiert (das ist ja nur ein binary plus eine Konfigurationsdatei) und werte meine Logs dort aus. Ich muß die Logs also nicht übertragen.
Ok, auch eine Möglichkeit. Allerdings -wenn's klappt- bin ich eh nur noch zwei, drei Wochen dort und dann wird sowieso alles viel besser, schöner, größer, bunter und überhaupt und so weiter. Und ich brauche mich endlich nicht mehr über die Fehler anderer zu ärgern, sondern darf meine eigenen machen ;)
Gruß,
soenk.e
-
-
-
-
-
-