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] -~----------~----~----~----~------~----~------~--~---
