Another option, although it would fall into your less preferable category would be to run the quercus version of PHP http://www.caucho.com/resin-3.0/quercus. Its PHP rewritten in Java. Its supposed to be as fast (if not faster) than apache+php+accelearator. One of its good points is that it is free of seg faults, because its Java based. There are a few references on the net to people running Drupal sites off it and getting very good performance gains. I've installed a demo site for myself and it works well. I have not tried it on anything production yet though.
chris burgess wrote: > We've got a server which is kept fairly busy with a couple of largish > sites running Drupal (5) + Wordpress. Between them the sites served > 750,000 pages a month last month; this should triple shortly (based on > previous marketing campaigns). > > Current load is moving towards capacity for the frontfacing webserver > (DBs hosted on a separate VM) and it seems that most of the server's > work is CPU load compiling scripts, so I've been testing out a few > opcode caches. The resulting performance boost is great, but with both > APC and eAccelerator we see segfaults after a few hours (quicker with > eAccelerator). > > If I can get rid of the segfaults, I'll be a lot more confident about > weathering the upcoming load, and I'd like to know what other folks > experience of opcode caches are, and how you've tamed yours. > > I guess what I don't fully understand is what triggers the segfaults. > From my observation, it's not so much the time the process has been > running as the number of requests that its handled - which could > suggest that it's just a game of roulette, and any given request has a > 1/10000 chance of segfault. Ugh. > > Ideally, I want to fix things so the opcode cache behaves, without > dropping requests on a segfault (even a few a day is too many in my > book - we need to project a high standard). > > Some crude options I'm considering, if segfaults are just accepted > practice with an opcode cache ... > > * forcing apache2ctl graceful at regular intervals - but this is > like driving with an oil leak and three spare cans of oil - it's > just not right > * setting maxrequests low enough that apache will restart each > process before it has a good chance of segfaulting > > Some alternatives, which I'd prefer to avoid because I don't want to > rock the config too much: > > * reverse proxy with pound > * move static files to a non-php virtualhost with mod_rewrite (but > would the redirects count as requests, for the purposes of > segfaults?) > * more extreme tactics like lighttpd > > I'd really appreciate any suggestions / input. (Open to commercial > support offers too, of course.) > > Thanks in advance > > --------- > > *Details, details* ... > > Servers are Xen domUs running Debian Etch, with the front-facing > webserver on one CPU and the DB server on the other. CPUs are 2.33Ghz; > DB server has 2GB RAM, webserver has 3GB. There's also a mostly idle > domU for testing. Apache2 MPM prefork, PHP5 from current Debian Etch > packages. eAccel is from the packages by Andrew McMillan. > > Drupal is 5.10 with normal Drupal caching, and Wordpress is 2.3.3 with > its builtin caching enabled. > > Configs tested with: > > APC: > > apc.enabled = 1 > apc.shm_size = 256 > apc.max_file_size = 10M > apc.stat = 1 > apc.shm_segments = 1 > apc.mmap_file_mask = /tmp/apc.XXXXXX > > eAccel: > > [eaccelerator] > eaccelerator.shm_size="256" > eaccelerator.cache_dir="/var/cache/eaccelerator" > eaccelerator.enable="1" > eaccelerator.optimizer="1" > eaccelerator.check_mtime="1" > eaccelerator.debug="0" > eaccelerator.filter="" > eaccelerator.shm_max="0" > eaccelerator.shm_ttl="0" > eaccelerator.shm_prune_period="0" > eaccelerator.shm_only="0" > eaccelerator.compress="1" > eaccelerator.compress_level="9" > > > > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.169 / Virus Database: 270.7.5/1706 - Release Date: 10/3/2008 > 6:17 PM > > --~--~---------~--~----~------------~-------~--~----~ NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
