EdisonReport.net site loading Slow if at all
PermalinkThese are the figures I got: http://www.webpagetest.org/result/121127_YE_TW7/1/details/...
Have you read this by Andrew?
http://andrewembler.com/posts/5-easy-ways-to-speed-up-a-concrete5-s...
http://andrewembler.com/posts/improving-the-performance-of-zend-cac...
Where is this being hosted?
<IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSIE !no-gzip !gzip-only-text/html SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary </IfModule>
@beingalex... My experience is that compression techniques don't help much with TTFB issues and can sometimes make things worse but gzip certainly helps bandwidth issues.
Having had a quick look at the site, I think it's the sheer number of page objects being loaded with all the requisite mySQL queries that go with that. Having that many items in your page list block will bring most servers to their knees.
I think it's a mySQL issue because every once in a while I get a concrete5 error message telling me it can't connect to the database. See attached.
Have you complained to Bluehost about a 60 second TTFB?
ourladyschurchdown.org.uk
so I copied the entire site temporarily to another host who are smaller and recommended to me to test their service and couldn't believe how much better performance was (and on a shared server).
wickmedia.co.uk/speedtest
and got dramatic results, see attached images. I made loads of recommended changes as outlined in various forums and posts on Concrete5 site but nothing is helped more than changing to a better, less busy host!!!
I've since done the same with another Concrete5 site and found site speeded up 6 times from 20 seconds to 3 seconds. Host was wickmedia.com in UK. test above for yourself.
All the tweaks in the world can't fix an over-loaded host. And their tech support staff will NEVER admit that their overloaded so that's a useless conversation. You might think you've fixed it because it works fast after midnight but then tomorrow at 7pm the problem returns when the server gets overloaded again by prime time usage.
I'm with TMD Hosting and pay $3.85/month and my sites have a TTFB of about 1-2 seconds which is pretty good for $3.85.
Just for comparison, concrete5.org measures between 7 and 15 depending on the time of day. My cheap hosting plan runs between 2-3 on this test during prime time and there are about 400 other sites on my shared host
I wouldn't put too much stock in the "Concurrent Test" from that site as a load indicator for TTFB problems.
It relies on HEAD requests which still requires parsing of the PHP and, as it has to go through the index.php, will always show dire results for misbehaving sites.
I even have a KVM machine with a TTFB of 200ms, a few links on a page and webpage test results of 400ms for a full page load which shows a worse concurrent test result than all of my shared servers that have thousands of others. That's just stupid!
A better indicator of server load is to find a direct linked file (like CSS) and run that through webpagetest.org a few times and see what the TTFB is. This will give you the servers response time without going through the CMS.
Would it be possible for you to develop a simple dashboard item that would run through some server load tests. As you are well aware, this is a question that comes up in the forums at least 5 times a day. It would really be nice to have a tool that narrows the problem down a bit.
Webpagetest.org is all that you need. It's just a case of understanding what it's telling you.
However. TTFB problems cannot be remotely diagnosed. The only way is to replace certain files in the concrete5 core with the ones I posted on another thread that gives you all the timings so you can see what is taking the time. However. This much I do know.....
The main problem (there are a few) is the Zend cache ESPECIALLY if it's being used on an updated site. This has only really become a significant issue since 5.6 although I suspect it has always existed; just not been so heavily utilised and therefore less apparent. The the best thing (or rather, safest without re-installing) you can do if it's happening to you is to downgrade your site so that it is working out of the main directories rather than the update, turn the cache OFF and delete everything in the cache directory. Depending on your site, that "may" be enough to get back to sane timings, but still, it's not guaranteed. You may still end up with a slow site, but it will be nowhere near these sorts of times.
You may also be interested in this
http://www.concrete5.org/community/forums/chat/looking-for-beta-tes...
Maybe that's why none of my 5.6 sites have shown a problem. I manually update all my sites by renaming the concrete folder to the old version (e.g. 'concrete5.5') and then I replace the concrete folder with the one from the 5.6 archive. I find it much more intuitive that way.
I started doing it this way because I found it really hard to diagnose problems when the paths to all the files was really long. I was spending most of my time drilling down with Filezilla to find the files. By the time I found the file, I forgot why I was looking for the file!
I also clear my cache and turn them off (if they were actually turned on in the first place) and switch my theme to one of the core themes before running the update script. I can't say I have a perfect record at updating but so far this procedure has served me well.
I tried your suggestion on running a direct linked file, in this case CSS, through webpagetest and get the following readings. Does this indicate a slow server as seems to vary on the Time to First Byte.
Test1
DNS Lookup: 103 ms
Initial Connection: 133 ms
Time to First Byte: 2918 ms
Content Download: 4 ms
Bytes In (downloaded): 2.0 KB
Bytes Out (uploaded): 0.5 KB
Test2
DNS Lookup: 49 ms
Initial Connection: 132 ms
Time to First Byte: 1450 ms
Content Download: 3 ms
Bytes In (downloaded): 2.0 KB
Bytes Out (uploaded): 0.5 KB
Test3
DNS Lookup: 48 ms
Initial Connection: 135 ms
Time to First Byte: 402 ms
Content Download: 14 ms
Bytes In (downloaded): 2.0 KB
Bytes Out (uploaded): 0.5 KB
It shows 26.67s loading time.
Rony