----- Original Message -----
From: "Jochen Metzger" <[EMAIL PROTECTED]>
To: <users-de@httpd.apache.org>
Sent: Wednesday, September 11, 2002 1:12 PM
Subject: Re: Verständnisfrage zu Kindprozessen
> Hi Joerg,
> > > Timeout 300
> > > KeepAlive On
> > > MaxKeepAliveRequests 100
> > > KeepAliveTimeout 15
> > > MinSpareServers 5
> > > MaxSpareServers 5
> > > StartServers 5
> > > MaxClients 150
> > > MaxRequestsPerChild 0
> >
> > 0 ? Null ???? Ja sag mal bist du wahnsinig. Das heist das dein Child bis
> zum
> > Sanktnimmerleinstag Anfragen beantworten muss. Sag ihm dringend das er
das
> > nur bis zur Rente machen soll. :)
> > Wie lassen 'nur' 150 Anfragen zu und danach wird der Child automatisch
> > beendet und ein neuer geforkt. Prima sache wenn man mit MemLeaks
zukämpfen
>
> Und habt Ihr KeepAlive trotzdem on?
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.
Wer das auch mit PHP Scripten machen moechte muss die gr. von Hander mitteln
und den Header('Content-lenght') zu Fuss setzen oder aber mod_gzip benutzen.
Unsere Probleme begannen als wir Content an Tonline abgegeben haben und
diese dann anfingen von ihrer Startseite und den Umweg über Frames auf
unsere Kiste zuverlinken. 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.
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. Desweiteren wurden 'Einschlagsseiten' so umgestellt das
diese ihren Inhalt cachten um somit DBanfragen, Templategenierung
zuvermeiden. Aber immer noch genug PHP drin :) Hinzu kam der Einsatzt vom
PHPaccelerator ,welcher aber bei uns Nebenwirkungen zeigt(*). Nun kommen wir
mit 100 Childs aus und man kann das Wochende durchschlafen :)
> 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
2. OS und Compiler spezfische Optimierungen
3. Beim Einsatz von Perl,PHP,JSP whatever... der Speicherverbauch des
Scriptes selber
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 :)
> 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.
Ob wir kleinere Memleaks haben weis ich nicht. Wie geschrieben beantwortet
bei uns ein Child max. 150 Anfragen und geht danach in den Ruhestand.
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.
(*) Der PHPaccelerator foerdert ein PHP problem zutage wo in Abhaengingkeit
von Configparametern und Laufzeit bzw. Anfragen der Speicherverbrauch eines
Sriptes immer groesser wird. Auf diese weise haben wir die 8MB default
Grenze von PHP ueberschritten was entsprechend dafuer sorgte das anstelle
der Seite nun Fehlermeldungen angezeigt wurden. Aber das Problem war schon
vorher bekannt und wir entsprechend vorgewarnt.
So, das alles wird dir nun bestimmt nicht weiterhelfen zeigt dir aber das du
nicht der einzige mit Problemen bist :)
An deiner Stelle wuerde ich mir einen aktuellen 1.3.x Apache bauen mit nur
den Modulen die du brauchst. Fuer PHP und seine vielen Extensions gilt das
gleiche. Solltes du einzelne Extensions von php nur in wenigen Seiten
brauchen...dann baue diese als name.so und lade sie gezielt in einzelnen
Scripten.
Gruss
Joerg Behrens
--
TakeNet GmbH Mobil: 0171/60 57 963
D-97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
