|
Monday 29 November 2010 9:59:52 am
@Doug excellent idea, even though I'd normally go for putting as much stuff as you can in your APC cache. But the best thing is: if you remove from the APC cache all the files generated by eZ, you can then simply 1. tell APC not to check the staleness of its cached files vs. timestamp of original pph files on the fs (apc.stat=0 in php.ini) and get a speed boost and IO pressure decrease on your fs (great if your install is eg. on NFS) 2. remember to clear APC cache by hand after every delivery of a new site update Could you provide us with some numbers about page load times / reqs per sec. before and after the change? One thing to note though: you might want to tune your templates, you might have cache-blocks that keep churning (use ggsysinfo to get a graph of the number of files-added-in-the-cache-per-minute on your install), as otherwise your apc cache hits should be much higher - f.e. the php files in the template cache should never expire, and be good candidates for APC caching. Or you have just too little of shmem given to apc. What is your usage of it's allocated memory? Going slightly OT: a lil' while ago I experimented with the best format to be ideally used for storing those caches that are basically data structures: plain php or json or serialized php. The goals: - try to use a format that is not cached by APC and friend by default, as it is basically memory wasting - have the format that is both faster to load and using less memory for deserialization It is to be noted that right now eZP uses all of those formats for different caches - picking a single format would also help in the overall goal of cleaning up cache management mechanics. In the end my tests where not conclusive: depending on php/os version and presence or not of an accelerator the results changed. But I'd be happy to pick them up again if anybody else is interested...
Principal Consultant International Business
Member of the Community Project Board
|