I am running into a problem where my pages load very slowly during cache generation (similar to the problem reported here. I am using page caching (disk basic), minify (disk), and database caching (disk). My timeout lengths for page and database cache lifetimes have been substantially increased. Once the cache is generated, they do indeed load again very quickly.
An oddity I noticed while trying to research the problem is that the initial page load time (during cache generation) actually *improves* substantially when I enable “Debug Mode”. Any clue as to why this might be the case? I am wondering if this behavior can help me solve the slow cache-generation issue overall.
I received some guidance from the W3 Total Cache folks, and decided to run some tests that I can share with them. Here is what I am seeing. Between each test, I deleted all cache items before the following test. These are the initial cache-generation load times for my home page (www.pmkelly.com), using subsets of the following optimizations:
Page Caching (disk basic)
Minify Caching (disk)
Database Caching (disk)
I should point out that I tested this with “disk enhanced” for the page caching as well, and the results are the same. In my case, though, I am unable to use “disk enhanced” for my site overall because I require “Cache URIs with query string variables”.
What I find (unscientific timing, but illustrates the point well):
Debug OFF / Page Cache ONLY = 23 seconds
Debug OFF / Database Cache ONLY = 28 seconds
Debug OFF / Minify Cache ONLY = 24 seconds
Debug OFF / ALL THREE = 27 seconds
Debug ON / Page Cache ONLY = 7 seconds
Debug ON / Database Cache ONLY = 7 seconds
Debug ON / Minify Cache ONLY = 7 seconds
Debug ON / ALL THREE = 7 seconds
For the scenario where I am using all three optimizations, regardless of whether the Debug setting is on or off, the retrieval time is 2 seconds. So there is definitely something funny happening here related to “Debug” mode that is speeding up the cache-building process substantially. I don’t understand why. Does anyone out have any ideas at all?
Well, OK, it looks like I did not have the w3-total-cache tag associated with this thread when I started it. Apologies for missing that the first time. Any thoughts or suggestions?
For some of these timings, minify was “on” and for others it was “off”. I always saw the same behavior. When minify was “on”, all three settings (HTML minify, JS minify, and CSS minify) were turned “on”. I did not experiment with different combinations within that panel.
I just ran another quick test to confirm that the minify setting does not seem to affect the observed issue. The only variable that is significantly affecting speed during cache generation is whether or not debug mode is on or not. Once the cache is generated, though, all settings across the board deliver a page in about 2 seconds.
I should point out that I am testing this from a browser that is not logged in to wordpress, so it should be consistent with somebody visiting my site from the outside world. I manage the W3 Total Cache settings from one browser (Chrome, logged into wordpress), clearing the cache each time, and then load the pages from another browser (Firefox, not logged into wordpress).
Is there an easy place in the code where I can get it to not “write out” the debug information? That is, leave debug mode “on” so it speeds everything up, but then “turn off” the actual part of the code that puts debug information at the end of every file source? I like the speed, but do not really want all of that information out there on a daily basis.
Have you tried to clear your cookies? Debug mode pages are actually not cached, so this performance is odd.
I tried clearing the cookies, but continued to observe the same behavior. Your suggestion that debug pages are not being cached at all gave me another idea, though, and it does indeed appear that “debug mode” may be a red herring here.
What I noticed is this. When the plugin is *COMPLETELY* disabled, the pages all seem to load in a couple of seconds. That is the plugin is deactivated under the “Plugins” section in WordPress.
When the plugin is activated in the “Plugins” section, but the first option in W3 Total Cache is *UNCHECKED* (Deselect this option to disable all caching functionality) and “Debug Mode” is *NOT* selected, then the load time for each page is about 23 seconds.
And finally, when the first option in W3 Total Cache is *CHECKED*, the test results are all consistent with the findings I reported two weeks ago.
So it seems that there is some “overhead” associated with cache generation that is extremely slow on my site… and this slowdown is observed even when all caching function is disabled from the W3 Total Cache settings panel.
I still cannot guess what is causing this anomaly. Best if you submit a bug submission via the support tab of the plugin so I can see your settings (they’re including in the submission even if you do not provide site access) etc etc.
I can second this behavior. I am seeing the exact same results. I was at first just trying to figure out why I had such a long server response time lag with W3TC turned on (even with APC enabled). My page load times were great – but the initial server response was unbearable. It was bad in the Admin too, where you wouldn’t think W3TC would be an issue.
When I finally disabled W3TC, my server response times were near instantaneous, but the page load of course was much longer. I was getting a consistent 7 second lag on an in-house clean development server, but no lag with the plugin off.
I then found this topic, and tried the hint of turning on debug mode. My lag dropped to 2 seconds (and that last 2, as confirmed in the debug mode results at the bottom of the page, included some plugin queries that took far too long).
This is on WP 2.9.2, on a windows server, with everything up-to-date, a slew of plugins, and a DB consisting of 250 authors, 11,000 posts and 140,000 comments.
I never suspected W3TC, which was making my pages load wicked fast, would be causing the lag. When I was observing our live server statistics in real-time, I could see the CPU never got above 5% usage, and our 8GB of RAM was only hovering at about 30% usage. So it made no sense that the server was taking so long to respond (on the live server, up to 15 seconds) and begin streaming the page data – there was no stress on the server of any kind – just a long pause.
Quick followup – there’s definitely something happening with the wp-admin when W3TC is active. If I disable the plugin, I get virtually no lag going from page to page (comments, edit posts, etc.). With the plugin active (though disabled from cacheing, as confirmed in the debug output on the wp-admin pages), the 7-12 second server response lag comes back – and the debug output shows that the query time was only 0.078!
One thing that will almost always cause the server request to timeout completely (and return a blank page) is clicking “empty all caches”…
- The topic ‘[Plugin: W3 Total Cache] Debug Mode Improves Performance?’ is closed to new replies.