While looking through this WordPress performance post I realised that eAccelerator might not be running properly on this blog. For some time I’ve noticed this site hasn’t been as quick off the mark as it used to be. Dare I say it, but it was even a little sluggish!
If you’re not familiar with it, eAccelerator is a PHP accelerator. It caches PHP bytecode and performs optimizations to make your PHP site run a lot faster.
I verified that eAccelerator was loaded and then checked my php.ini configuration. Sure enough, the eaccelerator.cache_dir directive was set to “/tmp/eacc/” and that directory was deleted the last time my server rebooted.
A permanent fix is to change the location of the cache dir. Put it anywhere the webserver can read, but don’t put it in /tmp/.
While you’re looking at eAccelerator, upgrade to the latest version, especially if you’re running PHP5.
You may want to try out XCache instead of eAccelerator. I’ve found it to be a bit faster and on most systems you do not need a cache directory as it maps to /dev/zero.
XCache Main Site:
http://xcache.lighttpd.net
I’ve written about it a few times on my site and binaries for EL4 & EL5 w/ PHP 5.2.x are included in my yum repository.
I’m sure I tried Xcache before but with disastrous results. It didn’t work at all! I’m willing to try it again though. Maybe next week when things quieten down here. Thanks Jason for the suggestion!
Donncha: I have worked with eaccelerator for years now and I can tell you that:
– newer versions than v0.9.4-rc1 don’t check the existence of check_cache_dir when shm_only = 0 (it should be like that by default, as i am not sure why would anyone want to cache on disk also).
– meaning that in the above case you can have eaccelerator.cache_dir pointing to any directory (even nonexistent) and ea will work just fine.
– if this is not the case for you then as you mentioned you should put the cache folder outside of /tmp
ps. most linux distros (including debian that you seem to be running) clean up the /tmp folder on system reboot. If you want that disabled you can edit the file /etc/default/rcS and tune the TMPTIME parameter (default to 0 days) to keep your tmp files for how many days you require.
Cheers,
– Marius –
eAccelerator still is not safe for production servers. I was using it but I got segmentation fault errors that caused apache crash, and in some times the whole server was crashing.
I guess that the best option for caching at the moment is mem_cache
Marius – I Have shm_only set to 0 but there is value in caching to disk. The OS disk cache will probably cache the file in memory anyway, and in the case that all shm memory is used it’s probably better to cache to disk than not at all right?
Nick – it’s working fine here and elsewhere, but sometimes PHP apps do odd things that break these accelerators. I use memcached too, but that’s a different class of cache. It caches high level data for PHP, whereas eAccelerator caches the actual bytecode generated by PHP when it compiles your php scripts.
Another vote for xcache, i use it for personal sites and for work’s web hosting, works brilliantly!
I’ve been using Nginx, PHP5 on FastCGI, and APC on one blog and it works well.
Poor showing by your boys against Namibia.
Hon – something else to try at some stage!
I guessed you meant the Rugby World Cup but I searched just to be sure .. 32 – 17? Not much of a margin alright!
Donncha: I my earlier comment, I obviously meant eaccelerator.shm_only=”1″ and not 0… Sorry about that. If you want you can edit my previous comment with this change as that was what I meant. Cheers, M.