RootForum Community

Wieso vergleichst du nicht einfach den 12. mit dem 18. ?

Dort hast du nur sehr gering mehr Visits, und über doppelt soviel Traffic.

Ich denke, da spielt dir einfach das Surfverhalten deiner User mit rein. Außerdem gibts viele Files, die nicht gegzipped werden, wie zB Bilder oder große Files.

Es kann einfach von der Logik her nicht sein, dass deine Seite mit mod_gzip mehr Traffic verursacht als ohne. Weil selbst unkomprimierte mod_gzip gepackte Seiten brauchen ähnlich viel Platz wie Seiten ohne mod_gzip, aber auf keinen Fall mehr.

Das der Webalizer da was falsch auswertet, könnte ich mir sogar vorstellen, da er denkt, wie oben schon geschrieben: index.html => gzip => index.html.gz und deshalb da in Chaos ausbricht.

Aber was glaubst du, warum Millionen richtig große Seiten mod_gzip verwenden, und dadurch unmengen Traffic einsparen, und zudem noch den ISDN und Modem Usern eine Freude machen ? zB benutzt dieses Forum hier auch mod_gzip und hat dadurch entscheident weniger Traffic.

Vielleicht hast du aber auch mod_gzip falsch konfiguriert, am besten du testest mal, ob deine Seiten überhaupt mod_gzip kompirmiert versendet werden.

kase wrote: Es kann einfach von der Logik her nicht sein, dass deine Seite mit mod_gzip mehr Traffic verursacht als ohne. Weil selbst unkomprimierte mod_gzip gepackte Seiten brauchen ähnlich viel Platz wie Seiten ohne mod_gzip, aber auf keinen Fall mehr.

Das sind auch meine Erfahrungen. gzip bringt bei uns ca. 30% weniger Traffic. Aber ich kenne die Stats von Enny - nur verstehen tue ich sie nicht :(

kase wrote: Das der Webalizer da was falsch auswertet, könnte ich mir sogar vorstellen, da er denkt, wie oben schon geschrieben: index.html => gzip => index.html.gz und deshalb da in Chaos ausbricht.

No Sir ...
Gzip ist für den Webalizer völlig transparent!

kase wrote: Aber was glaubst du, warum Millionen richtig große Seiten mod_gzip verwenden, und dadurch unmengen Traffic einsparen, und zudem noch den ISDN und Modem Usern eine Freude machen ? zB benutzt dieses Forum hier auch mod_gzip und hat dadurch entscheident weniger Traffic.

Vielleicht hast du aber auch mod_gzip falsch konfiguriert, am besten du testest mal, ob deine Seiten überhaupt mod_gzip kompirmiert versendet werden.

Tun Sie - die Config ist auch ok. Das ist ja das, was ich dabei nicht verstehe.
Wobei ich sagen muss, dass ich den Server nicht aufgesetzt/compiled habe - aber so viel kann man da nicht falsch machen :)

Ennys Probs sind etwas "strange" .....

Also ich weiß jetzt nicht, was dein Server ist, aber ich vermute, das hier:

http://www.gesl.de/index.html

Und diesem konnte ich keine einzige gzip-Seite "entlocken".

Also entweder, es ist mom deaktiviert, oder es ist wirklich was falsch eingestellt.

Falls du es aktivierst, könnte ich mal nachschauen, wieviel Byte Daten mir bei einer Anforderung mit/ohne gzip zugesendet werden, was deinem Problem doch einen entscheidenden Fortschritt liefern würde.

kase wrote:Also ich weiß jetzt nicht, was dein Server ist, aber ich vermute, das hier:

http://www.gesl.de/index.html

Und diesem konnte ich keine einzige gzip-Seite "entlocken".

Also entweder, es ist mom deaktiviert, oder es ist wirklich was falsch eingestellt.

Falls du es aktivierst, könnte ich mal nachschauen, wieviel Byte Daten mir bei einer Anforderung mit/ohne gzip zugesendet werden, was deinem Problem doch einen entscheidenden Fortschritt liefern würde.

Um enny vorzugreiffen (er hostet den Server bei uns und hatte mich auch gefragt):
gzip ist im Moment deaktiviert, nach seiner letzten Aussage.
Die Stats des Routers bestätigen im Ã?berigen seine "Vermutungen". Allerdings hab ich keine Ã?bersicht über Hits/Visits, aber bei der Menge die er hat sollte sich das statistisch zu Gunsten von gzip auswirken....

Und da passt es leider nicht :(

Hier mal als Beispiel:

die Rootforum Index-Seite http://www.rootforum.org/forum/index.php sendet mir, wenn ich dem Server mitteile, KEIN gzip zu unterstützen, 35197 Byte Klartext-Daten inkl Header, also ca 35 kb.

Wenn ich dem Server mitteile, gzip zu unterstützen, sendet er mit 5718 Byte, bestehend aus Header und gzip compressed Data, also knapp 6 kb. Auf meinen Seiten verhält es sich ähnlich. 30 % Traffic-Ersparnis ist sogar recht wenig bei Seiten mit wenigen Bildern und ohne Downloads. Meist fällt es deutlich mehr ins Gewicht.

Wenn du mod_gzip mal aktivieren würdest, könnte ich diese Angaben mal überprüfen.

So weit hab ich das nicht geprüft :)
Ich hatte nur geschaut ob der Server gzip nutzt oder nicht.

Ich denke enny liest mit und kann dir selber antworten :)

Aber schön zu sehen, dass es doch noch Leute gibt die versuchen ein Problem zu lösen und zu verstehen :)

BTW @ALL
APACHE2 mit PHP in Production (in Stosszeiten >5000 Hits/Stunde) ... hat da wer Erfahrungen?
Nach dem letzten Ausflug in die apache2 Welt und den damit verbundenen Problemen will ich vorher Erfahrungswerte haben :)

redhorse wrote:

Joe User wrote:warum steigst Du nicht einfach auf Apache2/worker/mod_deflate um, wenn Performance und Kompression soo wichtig ist?

Vielleicht habe ich die letzten Wochen ja was verpasst:
Seit wann läuft Apache 2 mit PHP in einer Production Umgebung stabil?

Wochen? Seit über einem Jahr: man CGI

joe,

ich will dir nicht zu nahe treten, aber:
Mein letzter Versuch war apache 2 anfang der 2.0.40iger .... mit php 4.3.1 oder 4.3.2, ssl, deflate (ist schon etwas her).

Und das war bei den o.g. hitzahlen alles andere als stabil und brauchte ca. 30% mehr cpu/speicher als der 1.3.28 mit gleicher config auf einem dual xeon 2x2.8 mit 2gb ram :(

Das es bei wenig last stabil läuft weiss ich auch .... aber wie schaut es wirklich bei hoher last aus?

edit: Damals suse 8.1 from scratch, alles andere inkl. apache und co selbst compiliert!

Moin,

redhorse wrote:joe,

ich will dir nicht zu nahe treten, aber:

keine Sorge, das tust Du nicht ;)

redhorse wrote:Mein letzter Versuch war apache 2 anfang der 2.0.40iger .... mit php 4.3.1 oder 4.3.2, ssl, deflate (ist schon etwas her).

Und das war bei den o.g. hitzahlen alles andere als stabil und brauchte ca. 30% mehr cpu/speicher als der 1.3.28 mit gleicher config auf einem dual xeon 2x2.8 mit 2gb ram :(

Mit welchem MPM? PHP als CGI, oder Modul?

redhorse wrote:Das es bei wenig last stabil läuft weiss ich auch .... aber wie schaut es wirklich bei hoher last aus?

Nur als Beispiel: Unter wieviel Last laufen die Server der Apache Foundation, insbesondere http://cvs.apache.org/? ;)

redhorse wrote:edit: Damals suse 8.1 from scratch, alles andere inkl. apache und co selbst compiliert!

Nun wären natürlich die jeweiligen ./configure --$options interessant ;)

Gruss,
Markus

Mensch, du stellst Fragen mitten in der Nacht :)

Ist wie gesagt schon ein bisschen her ...
Fürs compilieren waren die werte mehr oder weniger 1:1 übernommen von der 1.X apache Serie.

Muss mal schauen ob ich das Instlog davon noch habe ... geklappt hatte es ja *g* nur unter Last bracht das Ding zusammen :(
Ach ja ... Ich hasse module :)

BTW: cvs.apache.org
FreeBSD Apache/2.1.0-dev (Unix) DAV/2 SVN/0.29.0 mod_ssl/2.1.0-dev OpenSSL/0.9.7b 2-Oct-2003 209.237.227.194

Irgendwie steht da nix von PHP?!?!?!?
Hast Du bessere Infos als netcraft?

redhorse wrote:joe,

ich will dir nicht zu nahe treten, aber:
Mein letzter Versuch war apache 2 anfang der 2.0.40iger .... mit php 4.3.1 oder 4.3.2, ssl, deflate (ist schon etwas her).

Wenn Anfang 2.0.40'er =< 2.0.44 ist, war das allerdings grober Unfug. Zur Zeit von PHP 4.3.1 war 2.0.45 und bei 4.3.2 2.0.46 aktuelle. Damit hätte es geklappt...
BTW: Die Version findet man nicht nur über Netcraft raus...

redhorse wrote:Mensch, du stellst Fragen mitten in der Nacht :)

oops, war es schon wieder so spät :roll:

redhorse wrote:Ist wie gesagt schon ein bisschen her ...
Fürs compilieren waren die werte mehr oder weniger 1:1 übernommen von der 1.X apache Serie.

Ich hatte mir 10/2002 einen kleinen Testcase gebastellt:
P3 500MHz + 192MB SD-RAM 66MHz + 10GB IDE 7200
Als OSs installierte ich Win98SE, WinXPRC1 und SuSE 8.0 mit den jeweils zum Betrieb der damals aktuellen Apache2, PHP4 (CGI und Modul), MySQL3 und phpWebSite Versionen zwingend notwendigen Programmen und liess dann über drei Tage hinweg alle 5 Sekunden die Startseite von phpWebSite abrufen. Nun rate mal, welche Kombination am stabilsten lief - falsch, es war Win98 mit PHP als CGI, dicht gefolgt von SuSE PHP/CGI. Am instabilsten liefen übrigens WinXP und SuSE mit PHP als Modul...

redhorse wrote:BTW: cvs.apache.org
FreeBSD Apache/2.1.0-dev (Unix) DAV/2 SVN/0.29.0 mod_ssl/2.1.0-dev OpenSSL/0.9.7b 2-Oct-2003 209.237.227.194

Irgendwie steht da nix von PHP?!?!?!?
Hast Du bessere Infos als netcraft?

Glaube ich nicht ;) Ich wollte damit lediglich ausdrücken, dass im Regelfall nicht Apache für instabile Systeme verantwortlich ist, sondern vielmehr die diversen 3rdParty-Module, insbesondere mod_$Interpreter...

@oxygen:
Kann schon sein, dass es < 2.0.44 war :)
Ist, wie gesagt, schon etwas her.... Müsste direkt nach Erscheinen der Suse 8.1 gewesen sein.
bzgl. netcraft: schon klar, aber da sieht man die entwicklung der eingesetzen server/module

@Joe

dass im Regelfall nicht Apache für instabile Systeme verantwortlich ist, sondern vielmehr die diversen 3rdParty-Module, insbesondere mod_$Interpreter...

Full Ack!
Nur was bringt es mir, wenn ich diese Module (als Modul oder static mal egal) brauche.....
Zu deiner Testumgebung:
Verwundert mich bzgl. Win98 :)

Alle 5 Sek ein Zugriff sind aber für eine Produktionsumgebung nicht wirklich aussagekräftig. Bei > 50000 Hits/h sind wir bei ca. 14 Anfragen/sek :)

Trotzdem Danke für die Infos, ich werd den apache2 demnächst nochmal testen, wenn wir den einen Kunden auf Cluster umstellen :)

Könnt ihr nicht einfach einen neuen Thread aufmachen ? Das ist doch etwas zu Offtopic.

[offtopic on]
Was ich so von meiner "Umgebung" höre, setzen auch kaum Server-Admins Apache 2 ein, da er angeblich zu instabil bei großer Last läuft, insbesondere in Verbindung mit PHP. Allerdings habe ich persönlich Apache 2 noch nicht ausprobiert, vor allem, weil ich dessen Features nicht benötige.

Aber es gibt so ein paar Apache 2 Fanatiker, die dir bis zum letzten grauen Haar einreden, dass der Apache 2 stabil läuft, aber genauso gibt es diese auch bei den Apache 1.3ern, die dir einreden, dass Apache 2 nicht stabil läuft. Im Endeffekt hilft dir wohl nur, es selbst auszuprobieren. Brauchst du denn die Features vom Apache 2 (wenn ja welche) oder geht es dir nur ums Versions-Hunting ?

hast ja recht @kase

versionshunting ist mir egal, ich brauch was was stabil läuft :)
einziger vorteil von apache2 wäre für mich z.b. das deutlich schönere (weil einfacher) dflate und ssl.


und damit zurück zu ennys prob mit mod_gzip :)

Jo hab gelesen was Ihr geschrieben habt. mod_gzip ist derzeit deaktiviert.

Wäre noch ne Möglichkeit über die Logfiles herauszufinden wodurch die doppelten Hits/Files zustandekommen und ob bei den abfragen was verwertbares dasteht ... so beim grob reinschauen viel mir nix auf, muß mir das nochmal in Ruhe anschauen die Tage....

deine statistik die du uns da zeigst zeigt doch eher das es nicht mit gzip zusammenhängt, weil die anderen werte wo gzip nicht aktiv war ja auch irgendwo dazwischen liegen, also für mich als mathematiker ist dein bedenken gegenüber gzip unberechtigt *g*

da komm ich nicht ganz mit wie rechnest du?

Wen wir nach dem gehen was Hits und Pageviews bedeutet ist es unlogisch das wenn ich eine Seite mit sagen wir 20 Elementen aufrufe dann 40Hits erzeugt werden oder?

Erklär mir das mal bitte als nicht Matheprofessor? ;)

Wenn du mod_gzip mal 1-2 Tage aktivieren könntest, könnte man besser nachsehen, wo der Fehler ist. Wenn du es deaktivierst, isses nur ein "Raten".

Okay ich hab http://www.hwliga.de mit mod_gzip laufen .

Bei den Logfiles anschauen werd ich übrigens nicht ganz schlau drauß, das Logfile ist zwar bei den Tagen wo gzip aktiv war ca. doppelt so groß aber irgendwie find ich den "Fehler" net warum ca. doppelt so viele Hits/Files sind.
Es kommt der Aufruf der Seite dann die einzelnen Bilder/elemente ca. 30 jedesmal aber wo was doppelt sein soll .... hm naja mal sehen ob redhorse drauss schlau wird :)

http://www.hwliga.de/index.php

Ohne mod_gzip:

recieved:
36666 Byte (37kb)
header + no compressed data

Mit mod_gzip:

recieved:
6989 Byte (7kb)
header + gzip compressed data


Also die Daten sprechen für sich, und die Index.php wird mit mod_gzip auch MERKLICH schneller geladen, zumindest bei einem armen ISDN User wie mir :(

Edit: Was soviel heißt, dass zumindest Server => Client auf keinen Fall mehr Traffic entsteht. Vielleicht verursacht irgendein LOOP localen Traffic, der dann von IAM gezählt, sowie von webalizer erfasst wird.

Wie hast du die werte herausgefunden?

Der Traffic muss dann aber auch im Logfile sein weil der Webalizer das Log auswertet und das Log ist auch grosser bei aktiven mod_gzip.
Nur wie schon gesagt werd ich noob aus dem log net schlau warum und wie ...

Ich habe die Seite per GET requestet, einmal mit gzip und einmal ohne, und dann mit einem strlen() die empfangenen Byte gezählt, und zur Sicherheut mit einem printf() mir diesen empfangenen String nochmal anzeigen lassen, damit ich auch sicher sehe, dass es in dem gzip Fall auch gzip komprimierte Daten sind.

Hallo ich lebe noch ;)

So nun zu der Sache mit dem mod_gzip .
Ich muss erstmal was beichten bei einigen Seiten war ob_gzhandler in den PHP-Scripts aktiv (dumme Unkenntnis wenn man nicht selbst geschreibene Scripte verwendet).
Das würde auch den drastischen Trafficanstieg grade bei diesen Seiten/Stats die ich in den vorangegangenen Posts veröffentlicht habe erklären.

Nun denken sicher einige "So ein Dummkopf ... ich habs doch gleich gewußt.... Problem gelöst" schön wärs ...
Dem ist aber nicht so denn bei den Seiten die definitiv keine ob_gzhandler etc. verwenden (und diesmal meine ich definitiv habe alle scripte der Seite nach den ob_ und gz etc durchsucht), ist ebenfalls ein Trafficanstieg bei aktiven mod_gzip zu verzeichnen zwar nicht so viel aber immer noch ca. 20-30% mehr als ohne mod_gzip .

So ich habe die Tage mal noch etwas getestet und mich weitergebildet ;) .
Also an den Logs konnte ich nichts herausfinden was auf eine Ursache/Problem der mehr Hits/Files bei etwa gleicher Anzahl PageViews hinweist.

Vorgestern habe ich mich mal etwas schlau gemacht zu der zlib Funktion die bei PHP verfügbar ist. Dann habe ich diese mal aktiviert mit standard Komprimierungslevel -1 (höhere level bringen nicht wesentlich mehr Komprimierung aber erzeugen mehr Serverlast) dabei mod_gzip und ob_gzhandler natürlich deaktiviert.
Und eben nach erstellen der Seitenstats festgestellt das dieses Phänomen mehr Hits/Files nicht auftritt und dabei die Seiten die kein ob_gzhandler aktiv hatten mit zlib wesentlich weniger traffic erzeugen (ca. 20-30%) bei etwa gleichen PageViews ohne zlib.

Ich werde diese Einstellung (php mit zlib) erstmal so beibehalten da ca. 98% der gehosteten Seiten eh PHP sind und andere Dateien zu komprimieren selten sind oder wie Bilder eh nicht komprimiert würden mit mod_gzip.

So hier nochmal paar Seitenstatistiken:

2Seiten ohne ob_gzhandler , mod_gzip war aktiv am 11., 12., 15., 18., 22., 23., 24. und 25. , am 31. zlib aktiv :
http://gesl.de/error/site1.bmp
http://gesl.de/error/site2.bmp

Seite mit ob_gzhandler , mod_gzip war aktiv am 11., 12., 15., 18., 22., 23., 24. und 25. , am 31. zlib aktiv und ob_gzhandler deaktiv ; zusätzlich hatte ich am 22. und 23. was am logfileformat getestet deswegen dort auch etwas merkwürdige stats:
http://gesl.de/error/site3.bmp

Seite mit ob_gzhandler , mod_gzip war aktiv am 11., 12., 15., 18., 22., 23., 24. und 25. , am 31. zlib aktiv und ob_gzhandler deaktiv; am 14. hatte ein bot auf der Seite sein unwesen getrieben deswegen dort die seltsamen stats :
http://gesl.de/error/site4.bmp

Das mit zlib ist jetzt zwar keine richtige Lösung zu dem Problem sondern eher ein Workaround da ich immer noch nicht weiss warum mit mod_gzip mehr hits/files zu stande kommen , obs nun am kompilierten apache liegt, irgendeiner setting, einer datei die irgendwie anders ist als sie sein soll oder was auch immer ich falsch gemacht habe .....
Aber was solls vielleicht fällt jemand nochmal was ein oder ich hab irgendwann nochmal Lust zu testen oder sehe was zu der Sache.

So nun comments dazu :)