+1 of XCache, I haven't had any problems with it. 2008/10/6 Dalibor Andzakovic <[EMAIL PROTECTED]>
> I've had good experiences with xcache in terms of both performance and > segfaults. APC and eAccelerator were pretty unstable. You may want to look > into paid for Zend cache if previous 3 don't work for you. > > > > Tip #2, don't run your DB in a VM. Short story, IO issues. I've got a > significant (order of magnitude) throughput increase by running the DB > natively. This was VMWare Server and PostgreSQL. > > > > HTH > > > > dali > > > > *From:* [email protected] [mailto:[EMAIL PROTECTED] *On > Behalf Of *chris burgess > *Sent:* Monday, 6 October 2008 10:45 > *To:* [email protected] > *Subject:* [phpug] tuning opcode caches > > > > 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" > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
