piratos schrieb:
Für den [Seitenreport, Anmerkung d. Verf.] Webserver bedeutet das - er ist kurz vor dem umkippen.
Nein, die Auslastung des Seitenreport-Servers liegt in allen Bereichen durchgängig bei weniger als 0,5%. Ggf. hast du hier die von dir ermittelten Daten falsch interpretiert.
Wenn wir einfach mal das nehmen:
# www.seitenreport.de Gesamtzeit: 0.69701886177063 - Bytes pro Sek. 42875
## www.seitenreport.de Gesamtzeit: 0.70820999145508 - Bytes pro Sek. 42288
Das bedeutet das der komplette Inhalt im gzip Fall nach 0.708 und ohne gzip nach 0.697 komplett vom Testscript bzw. Empfänger empfangen wurde - erst dann kann man sie darstelen.
In diesen worst case Fall ist die Seite nicht schneller da - da weiss ich nicht wie du drauf kommst.
Sie ist nur dann schneller da wenn Fall 2 kürzere Zeiten hat und nicht längere, das ist doch völlig logisch.
Man hat also in dem Fall mit gzip 0 Vorteile als Besucher und in dem Grenzfall ist bei weiter steigendem Besucheraufkommen streng damit zu rechnen das die Serverlast sprunghaft ansteigen wird.
Wir haben das mit einem Hotelportal ausprobiert und abgeglichen so das wir für bestimmte Zeiten gzip abgeschaltet haben, weil das Nachteile bringt und zwar heftig.
Dennoch läuft die Seitenreport-Homepage meiner Meinung nach ohne GZIP langsamer. Für eine Demonstration/Prüfung, schalte ich die Komprimierung einmal kurzzeitig ab
(ab jetzt bis ca. 16.00 Uhr).
Hmm...
Ergebnis bei ausgeschaltetetem GZIP für Seitenreport:
# - gzip vom Testscript nicht frei gegeben
## - gzip vom Testscript frei gegeben.
Jetzt (erster Test):
# www.seitenreport.de Gesamtzeit: 0.67476391792297 - Bytes pro Sek. 44159
## www.seitenreport.de Gesamtzeit: 0.60324311256409 - Bytes pro Sek. 49395
Jetzt (zweiter Test):
# www.seitenreport.de Gesamtzeit: 0.67709398269653 - Bytes pro Sek. 44007
## www.seitenreport.de Gesamtzeit: 0.63097596168518 - Bytes pro Sek. 47224
Vorher:
# www.seitenreport.de Gesamtzeit: 0.69701886177063 - Bytes pro Sek. 42875
## www.seitenreport.de Gesamtzeit: 0.70820999145508 - Bytes pro Sek. 42288
Völlig klar und damit ebenfalls nachgewiesen ist, das gzip in vielen Fällen richtig etwas bringt, was somit auch sehr vorteilhaft für die entsprechende Domain ist.
Klar ist aber auch das es Grenzfälle und Fälle gibt wo z.B. gzip sich absolut nicht lohnt , sogar das Gegenteil bewirkt und die Behauptung gzip brächte immer etwas widerlegt ist.
Wir haben das bei einem der größten Hotelportale verfolgt und abgeglichen und schalten dort gzip zu bestimmten Zeiten einfach ab - das sind nun mal Werte aus der Praxis.
Und noch klarer ist, das Anbieter, die einen besseren Server und sei es nur einen Vserver oder shared Webserver verwenden ganz klar profitieren, weil die Leistung der Anwendung und damit den Besuchern zu gute kommt.
Das würde ja absolut in der Bewertung etwas bringen, weil diese Anbieter mehr für ihre Besucher getan haben, als andere die aus welchen Gründen auch immer ihre Serversituation als für sich ausreichend betrachten (was ja durchaus eine Kostenfrage ist).
Es geht ja letzten Endes nicht darum ob man an Inhalte (Größe der HTML) geizt sondern das man diese optimal an den Besucher bringt und wer da eben mehr macht der hat eine bessere Bewertung und das zu Recht.
Das dies alles auch etwas mit der eingesetzten Software selbst zu tun haben kann - aber ncht muss - dürfte allen klar sein, die jemals etwas mit Software egal welcher Art zu tun gehabt haben.
So wird ja hier auch glatt abgewertet, wenn man keinen Apache verwendet, obwohl in vielen Fällen für einen konkreten Einsatz ein MS Server erheblich besser ist. Ich denke da z.B. an die interne Einbindung eines solchen Servers an die Struktur eines Unternehmens.
Also wenn z.B. dein Web hier öfterns den Vorteil zum Nachteil dreht, eine relativ große Zeit benötigt um eine Seite zu schicken, dann liegt das bestimmt nicht an Typo3 sondern an der hohen Last durch fast täglich steigende Besucherzahlen hier, die natürlich sich auch auf den Seiten aufhalten, die für deinen Server richtig Arbeit bedeuten.
Wenn ich so sehe das du hier nur eine handvoll Domains liegen hast, die bis auf 2 inaktiv sind und andere erheblich mehr haben weil sie auf shared Webserver liegen und dennoch bessere Werte abliefern, dann kann es nur an der Serverlast liegen.
Da wirst du wohl über kurz oder lang etwas machen müssen, sonst wird dein Erfolg ausgebremst.
seitenreport schrieb:
Hmm...
Ergebnis bei ausgeschaltetetem GZIP für Seitenreport:
Ein mehrmaliger Seitenaufruf wird von dem Server über seine Cachemechanismen besser abgehandelt - völlig normal.
Es gibt da nie gleiche Zeiten, kennt jeder der etwas damit "gebastelt" hat.
wodurch aber doch auch folgende Werte verfälscht würden:
# - gzip vom Testscript nicht frei gegeben
## - gzip vom Testscript frei gegeben.
Dennoch: wenn ich es richtig sehe, ist die Ãœbertragung mit ausgeschaltetem GZIP für Seitenreport tatsächlich schneller (wenn auch nur gering). Damit hättest du Recht und ich Unrecht :wink:
Werde die Komprimierung mal vorrübergehend abgeschaltet lassen.
seitenreport schrieb:
wodurch aber doch auch folgende Werte verfälscht würden:
# - gzip vom Testscript nicht frei gegeben
## - gzip vom Testscript frei gegeben.
Das bedeutet nur das das Testscript bei ## in der Lage wäre gzip empfangen zu können, was nicht geprüft wird ob auch gzip gesendet wird. Musst den Text wörtlich nehmen.
<?php
function speedtest($domain,$zip=false)
{
$starttime = microtime(true);
$ch = curl_init(\'http://\'.trim($domain));
curl_setopt($ch, CURLOPT_TIMEOUT, 50);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HEADER, 1);
if ($zip)
curl_setopt($ch, CURLOPT_ENCODING,\'gzip\');
curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows; U;
Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1");
$curl_ret = curl_exec($ch);
$gesamt =microtime(true) - $starttime;
curl_close($ch);
$s=strlen($curl_ret) /$gesamt;
if ($zip)
echo \'
## \'.$domain.\' Gesamtzeit: \'. $gesamt.\' - Bytes pro Sek.
\'.round($s).\'
# \'.$domain.\' Gesamtzeit: \'. $gesamt.\' - Bytes pro Sek.
\'.round($s).\'
# - gzip vom Testscript nicht frei gegeben
## - gzip vom Testscript frei gegeben.
Ich habe das Skript mal auf zwei meiner Seiten online gestellt:
www.matthias-glaessner.de/test.php
Das zeigt, dass viele mit gzip besser fahren, und den zusätzlichen Vorteil des geringeren Datentransfers haben. Vor allem für Seiten wie heise dürfte das eh das Hauptargument sein, und nicht der schnellere Seitenaufbau.
Bytes/Sekunde finde ich auch irreführend, mir fällt aber auch nichts besseres ein.
seitenreport schrieb:
Ich habe das Skript mal auf zwei meiner Seiten online gestellt:www.matthias-glaessner.de/test.php
Ich halte allerdings den Begriff "Bytes/Sekunde" etwas irreführend, denn die Ãœbertragung ist ja hier nicht fließend, sondern ein CMS generiert die Seite ja erst, bevor diese verschickt wird (hierher kommt ja der Zeitverlust).
Ergebnis:
# - gzip vom Testscript nicht frei gegeben ## - gzip vom Testscript frei gegeben.
# www.seitenreport.de Gesamtzeit: 0.55439496040344 - Bytes pro Sek. 53723
## www.seitenreport.de Gesamtzeit: 0.5471088886261 - Bytes pro Sek. 54439
# www.matthias-glaessner.de Gesamtzeit: 0.083829164505005 - Bytes pro Sek. 384043
## www.matthias-glaessner.de Gesamtzeit: 0.086971044540405 - Bytes pro Sek. 374148
# webdesign.weisshart.de Gesamtzeit: 0.22177195549011 - Bytes pro Sek. 83081
## webdesign.weisshart.de Gesamtzeit: 0.20458793640137 - Bytes pro Sek. 90259
# www.rp-online.de Gesamtzeit: 0.3345410823822 - Bytes pro Sek. 440998
## www.rp-online.de Gesamtzeit: 0.033203840255737 - Bytes pro Sek. 4443793
# www.heise.de Gesamtzeit: 0.17319011688232 - Bytes pro Sek. 439361
## www.heise.de Gesamtzeit: 0.13449001312256 - Bytes pro Sek. 565953
# www.facebook.com Gesamtzeit: 0.75806307792664 - Bytes pro Sek. 37817
## www.facebook.com Gesamtzeit: 0.46325898170471 - Bytes pro Sek. 61935
# powercms.org Gesamtzeit: 0.076390027999878 - Bytes pro Sek. 266527
## powercms.org Gesamtzeit: 0.056883096694946 - Bytes pro Sek. 358648
Beitrag erstellen
EinloggenKostenlos registrieren