Hi, Chris, AFAIK MPM is not recommended in production environment unless you go with FCGI which is in turn often enough not recommended in conjunction with Zend. Anyway, prefork mpm and mod_php (+suhosin) have some issues with scalability. MaxClients is directly related to your server system's capabilities (see previous mail). Min/MaxSpareServers doesn't need any tweaking normally 5/10 or 10/20 should be more than enough. However I find it useful to set MaxRequestsPerChild to as low as 5000 where 10000 is standard. If you have uncertainties with memory leaks or weird beavior related to PHP then you can set it even lower to 2500. Just bare in mind that memory once allocated to a prefork child is never (!) released and that does include memory allocated by PHP. So there is the link to my recommendation to set MaxMemory for PHP as low as possible as each active prefork child will consume that memory after a short period of time.
Clarification: These are personal recommendations, all of the above is IMHO. If you go for production you should stress test your setup on your own. A good tool for this is Apache JMeter: http://jakarta.apache.org/jmeter/ Mit freundlichen Grüßen, With kind regards, Pascal Oblonczek, B.Sc. _______________________________________________ ELBNAH IT-SYSTEME GmbH http://www.elbnah.com Poppenbüttler Hauptstraße 33 22399 Hamburg Tel: 040 / 55613013 Mobil: 0179 / 2338953 Geschäftsführer: Pascal Oblonczek & Nico Oblonczek Amtsgericht Hamburg Handelsregister: HRB 110905 ----- Original Message ----- From: Chris Jolly [mailto:[email protected]] To: [email protected] Sent: Mon, 06 Dec 2010 16:01:50 +0100 Subject: Re: [oxid-dev-general] Caching-Problems with a 4.4.3 > Hi Pascal, as well as the php memory setting for OXID websites, do you have > recommendations for the apache prefork and worker MPM settings ? > (StartServers, MinSpareServers, MaxClients, MinSpareThreads, ...) Thanks & > regards Chris Jolly Ontraq Europe ________________________________ From: > Pascal Oblonczek <[email protected]> To: [email protected] Sent: > Mon, December 6, 2010 2:59:15 PM Subject: Re: [oxid-dev-general] > Caching-Problems with a 4.4.3 Hi, Kai, until you have a good reason, you > should reduce PHP memory size to max. 40megs. 256 is far, far too much, > don't forget that memory limit is per request! Ideally, with 110+ Clients > you shall reduce it to 22megs (2,5GB RAM / 110). Don't forget you have > overhead per request + Database memory. When RAM fills up, thrashing may > occur at DB level and MySQL ist very sensible to that and may tear down > your whole system. Oxid is quite hungry with RAM. Unfortunately memory > consumption per request scales heavily with number of > categories/manufactures and other core data structures. I guess this is due > to the fact that mostly all views are backwards compatible with old OXID 3 > views where full recordsets have to be loaded upon every request to serve > template variables, no matter if they will be used or not. In OXID 4 getter > methods have been introduced which may lower memory requirements if > templates don't request all core data structures for rendering. > Effectively, imagine you have 3gigs free, divide that by 256, thats 12 (!) > clients with full memory allocation and your setup goes boom. Finally it is > a good idea to user mod_proxy for load balancing. Better you get 100 happy > customers and 10 that get the clue what's going on (sth. like "Shop > overloaded, please check back later") than 110 with random failures. Mit > freundlichen Grüßen, With kind regards, Pascal Oblonczek, > B.Sc. _______________________________________________ ELBNAH IT-SYSTEME > GmbH http://www.elbnah.com Poppenbüttler Hauptstraße 33 22399 > Hamburg Tel: 040 / 55613013 Mobil: 0179 / 2338953 Geschäftsführer: > Pascal Oblonczek & Nico Oblonczek Amtsgericht Hamburg Handelsregister: HRB > 110905 ----- Original Message ----- From: Kai > Gazmaga [mailto:[email protected]] To: [email protected] Sent: > Mon, 06 Dec 2010 14:22:31 +0100 Subject: [oxid-dev-general] Caching-Problems > with a 4.4.3 > Hello folks, > > I have to maintain an Oxid CE 4.4.3 > with some modules on a dedicated > Server with 4 Gigs of Ram. The Server is > a managed machine from Webhost > One. I do not find any helpfull hint or > answer in the forums. We have > constantly 110+ users in the shop so it is > urgent to solve the problem! > > Here is the Problem: the shop does not > respond in a recuring manor - > every few minutes (maybe 30 or 60), we can > not say how often exactly. > The shop starts to slow down until we have no > reaction alt all (during a > few seconds). Further requests result in > several errors (header already > sent and some others). After about 2 or 3 > minutes everything is fine again. > > We now found out that we can trigger > the phenomenon manually by emptying > the tmp-folder. This results in a lot > of apache-processes switching to > deamonized mode. The number increases > until we hit the 200 and apache > restarts automatically. After this (or > manual restart of apache) the > shop and backend respond normally again. We > have 256 MB of RAM for PHP, > MySQL ist running normally and apache does > not show other unnormal > behaviour. Switching "keep alive" on and off does > not change anything. > > Did someone experience something similar or know > how to tweek apache or > the shop to solve this problem? > > Regards, Kai > aka SubNet-One > *Vektor*Design - Web-Programmierung > Kai Gazmaga > Neue > Strasse 83 > 89 073 Ulm Tel.: +49 731 - 3781953 > Fax: +49 731 - > 3781952 > Mail: info (at) vektordesign.de > Web: vektordesign.de > > > > > _______________________________________________ dev-general mailing > list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general > _______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
