Xcache module
Permalink
Long story short: I hacked up a quick cache module for xcache because debian/ubuntu come with php5-xcache packages right out of the box.
Seems to work fine unlike the eaccelerator cache handler, though I've not done very extensive testing.
If you're running multiple Concrete5 instances all using the xcache module you'll need to change the prefix it uses.
To enable the cache module dump xcache.php in your libraries/cache/ directory, edit config/site.php and add:
xcache.php should be considered public domain: do as you wish.
On a side note this came partially out of my frustration with Servage.net. All user directories are NFS mounted and really slow, this ends up with page loads taking 10+ seconds (most of which is spent reading from the filesystem cache).
So I tried using the eaccelerator module, except the memory limit is set so small that nothing stays in there for more than a few seconds...
Our other non-Concrete5 sites are blazing fast on Servage though... it's weird and their support team cant seem to be able to do anything about it.
Seems to work fine unlike the eaccelerator cache handler, though I've not done very extensive testing.
If you're running multiple Concrete5 instances all using the xcache module you'll need to change the prefix it uses.
To enable the cache module dump xcache.php in your libraries/cache/ directory, edit config/site.php and add:
define('CACHE_LIBRARY', 'xcache');
xcache.php should be considered public domain: do as you wish.
On a side note this came partially out of my frustration with Servage.net. All user directories are NFS mounted and really slow, this ends up with page loads taking 10+ seconds (most of which is spent reading from the filesystem cache).
So I tried using the eaccelerator module, except the memory limit is set so small that nothing stays in there for more than a few seconds...
Our other non-Concrete5 sites are blazing fast on Servage though... it's weird and their support team cant seem to be able to do anything about it.
hrm, why didn't I think of that! Using BASE_URL as the prefix seems to solve that very elegantly.
I cant remember if there are any limits on key size, though I've never run into one and a quick flick through the docs don't indicate anything.
Thanks :D
I cant remember if there are any limits on key size, though I've never run into one and a quick flick through the docs don't indicate anything.
Thanks :D
I'm going to test it someday as well since I'm using mostly debian linux on my servers..
Hope the core team will integrate this into c5!
Hope the core team will integrate this into c5!
Wouldn't take much to make this into an installable package right?
I haven't tested it, but are packages loaded before config/site.php gets included?
It might happen that with the use of a package, the cache doesn't work as effective as it could because lots of php code has already been executed and could have been cached..
Including it into the core shoudln't be a problem either..?
It might happen that with the use of a package, the cache doesn't work as effective as it could because lots of php code has already been executed and could have been cached..
Including it into the core shoudln't be a problem either..?
I have servage also but i have had no trouble as for the cache size i believe you can set it in a .htaccess file
That's really weird. I have 3 sites up and they all take 10+ seconds to load, no matter what I do.
While on Webfaction and my VPS its very fast...
While on Webfaction and my VPS its very fast...
Just going through and finding the source of cache misses which accounted for about 13%. Managed to squeeze another 4 or 5 requests/second. (concrete/models/block.php line ~115, the conditions around Cache::set aren't necessary.)
Even after all this I can count... around 370 database queries just on the frontpage? WTF
Even after all this I can count... around 370 database queries just on the frontpage? WTF
Have you had trouble flushing the cache using the xcache module? It was failing for me. It appears that xcache_unset_by_prefix is not in any stable releases of xcache. It looks like it will be available in 1.3.1.
This is nice. Is it a problem to use a longer prefix? Using the url (which is a global constant) would make it safer to use..