Better Performance with Partial Caching?
Permalink
I've analysed a few sites of mine and realized, that the cache (file, not APC) is often slowing things down. That might be because my MySQL server performs well and the file system doesn't but nonetheless I think it's worth looking into it.
I did the obvious thing, I turned off the cache (the basic cache!) and some sites were a tiny bit faster and some slower.
I then did some profiling and saw one part which is slow when I don't use any kind of cache: Page::getByID and within that function, 90% of the time was used to load the attributes.
On all sites I've tested, the best performance was reached when I only cached Page::getByID and nothing else. Things might be different with APC but when you use a slow cache backend like the filesystem, you'll probably also have a better performance if we'd only cache a few objects.
So far I haven't seen any option which would allow me to cache only certain object types. This is unless I want to hack around the core!
Does anyone have an idea how I could use a cache for Page::getByID but nothing else? Could we serialize all the attributes that belongs to a page on the row of CollectionVersions?
I did the obvious thing, I turned off the cache (the basic cache!) and some sites were a tiny bit faster and some slower.
I then did some profiling and saw one part which is slow when I don't use any kind of cache: Page::getByID and within that function, 90% of the time was used to load the attributes.
On all sites I've tested, the best performance was reached when I only cached Page::getByID and nothing else. Things might be different with APC but when you use a slow cache backend like the filesystem, you'll probably also have a better performance if we'd only cache a few objects.
So far I haven't seen any option which would allow me to cache only certain object types. This is unless I want to hack around the core!
Does anyone have an idea how I could use a cache for Page::getByID but nothing else? Could we serialize all the attributes that belongs to a page on the row of CollectionVersions?
By the way: With 5.5 about 80% of the time to load a page in the edit mode was consumed because of the dashboard menu on top. Again because it loads a lot of page objects!
Hmm - it should only load that page menu once, then it sticks it in session (just as HTML.)
For the dashboard menu, I mean.
Interesting, I'll look into that!
But honestly, I'm okay if the edit mode is slower. I can easily tell the customer that there are more components to load and he'll understand..
To me a generally faster Page::getByID would be much more beneficial.
But honestly, I'm okay if the edit mode is slower. I can easily tell the customer that there are more components to load and he'll understand..
To me a generally faster Page::getByID would be much more beneficial.
We don't really have a way to only cache pages – but we are looking into reducing the total number of cache entries to only those that cache significant amounts of data (e.g. pages, blocks, files)
Couldn't we include a parameter "level" in Cache->set?
In config/site.php we could then specify omsething like:
1 being moderate and 3 aggressive..
Checking that level in Cache->set shouldn't cost much and would add a great flexibility.
Reducing the number of cache entries might be wise, but for someone who can use APC it might be faster to have a big cache while memcache users should probably have a smaller number of cache entries and filesystem users even less.
In config/site.php we could then specify omsething like:
define(CACHE_LEVEL, 3);
1 being moderate and 3 aggressive..
Checking that level in Cache->set shouldn't cost much and would add a great flexibility.
Reducing the number of cache entries might be wise, but for someone who can use APC it might be faster to have a big cache while memcache users should probably have a smaller number of cache entries and filesystem users even less.
Okay it seems like my debugging/profiling environment cleans all that stuff to make sure it starts on the same level every time!
That does make the situation for c5 in real life a lot better, but I still think that Page::getByID could/should be improved..
That does make the situation for c5 in real life a lot better, but I still think that Page::getByID could/should be improved..
