Hallo Joerg, danke f�r Deine klasse detaillierte Info. Ich bin was die Serververwaltung betrifft noch relativ am Anfang und �ber jeden input dankbar. ;o) > Ja, weil es statische Elemente wie *.js, *.css und Bildformate aller art > gibt wo es dann ohne weiteres moeglich ist sofern der Client das moechte.
Hei�t das, da� der Client sich an genau den gleichen Apache-Bearbeiter wendet? Denn das meint ja IMHO Keep Alive oder? Da haetten wir in hoechst Zeiten 350 Childs > gebraucht um das abzuarbeiten. Hauptproblem war hier das die dynamischen > Seiten (php) zulange brauchten und so sich so das ganze uebelst > hochschaukelte. Aha, d.h. Bearbeiter ist mit Abarbeitung besch�ftigt, es werden neue Bearbeiter gestartet, die sind dann auch besch�ftigt usw. usw. > > Massnahmen waren den Apache zuentlasten in dem wir Bilder,CSS,JS ueber den > thttpd (geniales Teil :) auslieferten der auf einer 2 IP ueber Port 80 > konfiguriert war. Schau ich mir mal an: >Desweiteren wurden 'Einschlagsseiten' so umgestellt das > diese ihren Inhalt cachten Was habt ihr da genommen? php-l�sung? um somit DBanfragen, Templategenierung > zuvermeiden. Aber immer noch genug PHP drin :) Hinzu kam der Einsatzt vom > PHPaccelerator ,welcher aber bei uns Nebenwirkungen zeigt(*). Oh, gut zu wissen, wollte ich eigentlich auch in naher Zukunt einsetzen. Nun kommen wir > mit 100 Childs aus und man kann das Wochende durchschlafen :) Feini feini... > > > Wie gro� ist bei Euch ein Bearbeiterproze�? > > So eine Aussage hat keinen Wert. > 1. haengt es von der Anzahl der einzelnen Apache Module bzw. PHP(und seine > Extensions) ab Ah ja, so was habe ich mir schon gedacht. > 28527 nobody 9 0 9656 7456 5844 S 0 0.0 1.4 0:02 httpd > 361 nobody 9 0 6516 6328 6044 S 0 0.0 1.2 87:19 thttpd > > Auszug aus dem access.log > 212.185.220.*** 549081 - - [11/Sep/2002:13:50:32 +0200] > > 549KB werden hier durch das Script verbraten. Und das ist wenig und in > Hinblick auf (*) wirklich nichts. Beim Arbeiten mit Oracle sind Childs mit > 20MB die Anfangsgroesse :) Guter Hinweis --> Danke ;o) > > > Habt Ihr auch mit MemLeaks zu k�mpfen..... > > Ich kenne einzelne PHP Extensions bzw. die Libs auf denen sie beruhen. > Recode war mal so ein Fall wo sie die Childgroesse sich mit jedem Request > verdoppelte. Aha, das hei�t das mod_php k�nnte mit entsprechend einkompilierten modulen ein gro�e Fehlerquelle sein. > > Ob wir kleinere Memleaks haben weis ich nicht. Wie geschrieben beantwortet > bei uns ein Child max. 150 Anfragen und geht danach in den Ruhestand. > Gut, das probiere ich auch mal aus.... > Wie haben seit an 1 1/2 Jahren und somit ueber viele Apache/SSL/PHP > Versionen hinweg das Problem mit den <defunc> einzelner httpd Prozesse. > Wobei hier allerdings keine negativen Auswirkungen zusehen sind. Mu� man wohl mit leben, kein Indianer ist perfekt Greetz Jochen Metzger >
