Cache Causing Speed Problems4 users found helpful
I contacted the host (Bluehost) and they couldn't find any problems on their end. My client upgraded to a Pro Account in hopes that would help. I also went in and cleared the cache. At first, the new hosting account seemed to do the trick. The site was loading better, though still it was slower than it seemed it should have been.
I set up a check with Pingdom and have been monitoring the site for the last couple of weeks. After the initial drop-off in page load times, response times steadily began to creep back up. After a few days, the site was almost as slow as it had been before the upgrade.
I went in and cleared the cache again, and turned off full-page caching. Then I watched again, and the same pattern started. Page-load times increased by the hour. I went back in, cleared the cache and turned off the Overrides Cache. Page load time starting crawling up again. Finally I turned off all caching, cleared the cache one last time and since then the site has been loading in under two seconds for many days in a row. I've attached a graph that shows the period of time the site was slow.
I mainly wanted to bring this to the community to see if anyone else is having this problem, and if so, perhaps gain some insight as to why this would be happening. This site gets a decent amount of traffic (600-900 visitors per day). When I ran tests on the page load times, the lag was in the initial connection to the sever. The page would "wait" for up to 30 seconds sometimes before the first page elements would start to load.
The site is here:
Site is running on concrete5 184.108.40.206.
I've had exactly the same issue with exactly the same fix. VERY strange indeed.
Thanks to Phallanx for turning me on to this thread.
I wouldn't turn off the overrides cache. There's really no reason not to have it on and it doesn't use the other caching system that is slow on some servers.
How does it work?
I had to make ALL of the following changes. Doing them one by one, had no effect. Within a few hours of clearing the cache, my website (http://www.dmr.fm ) would be taking up to 15 seconds to load
Turn 'Basic Cache' Off.
Turn 'Full Page Caching' Off.
Set Full Page Rebuild to Automatic.
Clear the Cache.
After applying all of these settings, my website is loading in about 2-4 seconds instead of 8-15. We've been running it on these settings for about 72 hours so far, with no drop off in load times yet.
Of course, these are NOT ideal settings to run a website in. Hopefully Concrete5 issues an update to fix these new problems ASAP.
Meaning it doesn't do anything?
The "Overrides Cache" setting does not even exist on 5.5.x, right?
After I changed the cache settings as suggesting it loads a lot faster.
Thank you for posting this!
I've just been playing with the dispatcher.php. I stuck in a load of microtimes after every "section" to see what was taking how long.
It might be a worthwhile thing to do on on your set-up.
If site runs ok at certain hours and than like a snail... just means that some other site on hosting is using most resources at that time.
Cache on or off.... does not matter at that point.
Result: blazingly-fast website!
In the end, I still turned on the Overrides Cache, thank's to Andrew, and indeed it speeds up a bit the website.
Another thing I also did: change the Tracking Code from header to footer, which also helps a bit (quite important if you have Piwik as I do, since it's kind of a memory hog).
I am also sure that it's not related to the hosting, I've done several tests with pingdom.com and they all come down to this conclusion: the cache system of the latest Concrete5 is faulty (except Overrides Cache which seems to not share the same mechanism).
Thus, meanwhile we get an update: if you encounter some slowing issues with your Concrete5 website, disable all caches but Overrides Cache, then clear the cache. Also you can set the tracker code to footer if you didn't.
Here are some resources
Hope that helps a bit,
If it is not broken, then perhaps you can explain this to me since I am struggling to understand exactly how this works
This is an output from a benchmarking script when caching is turned on. The script is a modified dispatcher.php which has logging calls inserted throughout the script and just logs the time between calls.
0->start: 1350147643.5064 1->Requires1: 0.01619 2->autoloadCore: 2.0E-5 3->Cache::startup: 0.04849 4->app.php: 0.00304 ------------ repeated---------- 3->Cache::startup: 0.03305 4->app.php: 0.00356 ------------ ---------- 5->Requires2: 0.06851 6->Config: 0.00016 7->Includes: 0.00125 8->Requires3: 0.01111 9->site events: 9.0E-5 ------------ repeated----------
The number on the left hand side is an incremental number every time the log function gets called. I expect this to increment by one for each entry in the result. I have manually added the "---repeated---" to highlight identical calls.
Why are there repeated calls to the same section of the dispatcher.php (e.g Cache::startup) and how is it possible to jump straight to an individual section of the php file without first calling previous logging functions (i.e recall 5,6,7,8,9 without first calling 1,2,3,4)?
Are we looking at function caching and, if so, why are the functions called multiple times with the same arguments?
Here is one with caching turned off for comparison
0->start: 1350149018.8083 1->Requires1: 0.01725 2->autoloadCore: 2.0E-5 3->Cache::startup: 0.02627 4->app.php: 0.00352 5->Requires2: 0.06597 6->Config: 0.00036 7->Includes: 0.00154 8->Requires3: 0.01208 9->site events: 8.0E-5 <snip>
Note there is no replication and the numbers are contiguous.
Maybe it was before I was around? Anyhow, feel free to contribute as I feel like you have some great ideas. I'd love to see it.
As for those details, I can't be sure.
Could you attach some line numbers to the current dispatcher.php on github here?
What do you think is causing these issues?
And better yet, attach you profiling script?
No. I don't use git and as I said, I don't know what is going on (only that it smells like a kipper behind a radiator). The mod (at present) replaces the core dispatcher so can't really be integrated with the production version. That's not to say you couldn't put a debug switch in if you are so inclined. However, if the cache is broken (and we all suspect it is), then it is up to the core team to sort out such a fundamental issue (or at least respond to my post with an explanation)
I've already posted a version of the benchmarking mod on this thread
http://www.concrete5.org/community/forums/customizing_c5/slow-site1... (although it doesn't have the numbering) to try and figure out what is going on with that poor devils site.
And if you ever do get a github account it's at
Conspiracy? No. Apathy?. Yes.
Unfortunately, the file-based caching of the Zend Framework really doesn't work well for the number of objects that we're trying to stick in it. So we're going to take a different approach for the next major release of concrete5 (one that people probably would say we should have taken all along.)
1. Remove the usage of Zend Cache for all but a few small things (e.g. caching remote information about the picture of the day.) The library remains for applications and sites that need it.
2. Use in-memory once-per-request caching frequently, to ensure that the same database queries aren't repeated during a given request.
3. Try and actually reduce the number of queries that concrete5 runs. This is part of the "First make it work, then make it fast" philosophy: we've spent a lot of time on the "make it work" part - now comes the second part.
4. For block caching, store the fragments in the database instead of in Zend Cache. (Note: this might slightly reduce performance for systems that use APC Zend Caching, but it will improve performance for the 99.9% of sites that stick to the defaults.)
5. Make our full page caching fire much, much earlier in the process (e.g. if a page is in the full page cache, no database connection is made, and the page is retrieved before loading 99% of concrete5's code.)
6. Minor optimizations throughout.
If this sounds good to you, you might consider checking out the 5.7-performance branch. There are a lot of things happening in it. It's not production stable nor is there really that much to see in it. But under the hood things are happening.
That's great. But what about the ones that are suffering now? (and additionally, the many like me that cannot upgrade if/when there is one because the upgrade is also broken).
Are you saying that you acknowledge there is or has always been a problem with the cache and now understand what the issues are? What is your comment on the questions I raised? What is the "technical" explanation of why the cache can cause a site not to respond for 10s of seconds and deteriorates with time?
I really don't want to have to reverse engineer your whole caching system just so that I can help others when you know it inside out already and aren't! Throw us a bone here!
into their config/site.php.
In general, the main problem boils down to the Zend file caching being slow – or rather, just ill-suited to the sheer number of cache entries that concrete5 throws into it. Additionally, Zend Cache with the file backend has an issue where its garbage collection just seems to thrash a site and toss it into oblivion, if the site gets larger than some kind of nebulous point.
However, this isn't a permanent solution. In the past, we've tried to use the cache minimize the sheer number of database queries that concrete5 performs. Unfortunately, in some cases that meant actually adding to the number of queries, and then caching the resulting object. This actually leads to more queries, if the cache is off.
So instead, going forward, we're going to be removing reliance on Zend Cache for most things. Block-level record and output caching will be moved to the database, and in-memory caching should minimize most duplicate queries. Full page caching will be improved.
Finally, I believe the 10 seconds you're referring to is quite likely the problem with Zend Cache file garbage collection. Implement the suggestion at my link above (and then manually remove cache files periodically), go with APC, or turn off the cache.
That is only really an option for VPS/kvm since you need a console to install APC.
I've tracked down some of the problems to the "local cache" and the curious behaviour of the zend cache when multiple items with the same ID are inserted. Analysis of the "repeated calls" seems to emanate from the switching and reloading of the dispatcher when you have upgraded (I'd be interested to see if some of the people that are suffering are all using upgrades?).
By the way. I have successfully replaced the zend cache by using SQlite as a cache. This would be much more desirable than storing in a MySQL or other type of database especially for those that have their databases residing on a separate server. However, not all web service providers have SQLite installed.
I have just spent the last week working out Concrete 5 only to realise the cache does not work. No point using it then is there.
Thank god for Phallanx for outing the truth of the matter.
define('CACHE_FRONTEND_OPTIONS', serialize(array('automatic_cleaning_factor' => 0)));
1.define('CACHE_FRONTEND_OPTIONS', serialize(array('automatic_cleaning_factor' => 0)));
Question is, "where in the world is" site.php located.
I dabbled in cpanel in the past and I believe had access through ftp to the entire site, but so far I can't figure this out in Concrete5. help!
I've nearly lost one of my best clients thanks to this issue. This is no minor problem. For those who are unlucky enough to have experienced this, I feel your pain and I'm disappointed there hasn't been a formal notification from C5 on the matter.
This issue has been haunting me for the last two months, and it was incredibly difficult to investigate. I used tons of speed optimization tools, optimized all the resources on my site, all to no avail.
I'm just glad I've finally found the answer. Things are no loading much faster. Thanks so much Browningstudio!
Put the full page ..
Off- manually for some pages.
On - If block are ready.
>>>>> On - everytime. <<<<<<<<<<<<<<<<<<<<<<