EdisonReport.net site loading Slow if at all
Permalink
HELP! My site is loading very, very slow. We disabled statistics yesterday to speed it up and it helped. Today, it takes about 60 seconds to load. Will pay top dollar. Need a certified C5 consultant to help me fix immediately. Call Randy at 615-932-1029
Time to first byte is awful... for me it took 50+ sec. Are you on a heavily shared server? If so, you could change plan or host entirely...
These 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...
These 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...
Dedicated IP as far as I can tell. See attached
Where is this being hosted?
Where is this being hosted?
It is on Bluehost. I'll look at the attachment. Thanks,
Am on bluehost.
If you have mod_deflate enabled this code in .htaccess generally speeds up our sites. Some of them are stupidly fast!
<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>
My DSN report must be wrong then unless you have a dedicated server on Bluehost?
@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?
@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?
Thanks but I don't know what that means, could I hire you to go in and add this code for me? My email is reidrandy@gmail.com
Seriously, change hosts, I have had similar problems with a website hosted on a well known UK host and was thinging it was a problem with Concrete itself see...
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.
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.
I agree with trickylowe. That's why I tried to check to see how many other websites were being hosted on your server but the answer comes back as '1 domain' which is odd for Bluehost. Perhaps they've found a way to mask this number so clients can't find out that there are 1000 other sites on that poor server.
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.
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 to follow up on your server load issue. I put your site through a diagnostic website called 'www.unshit.com' (that's it's real name) and at the very end of the test, it tries to measure the server load by making some concurrent requests of your server that have nothing to do with your particular C5 website. They are just trying to test how busy the server is in general. I have attached the dismal results. Values less than 5 indicate a busy server. Your server rated 0.15 !! That's a busy server.
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
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
@mhawk
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.
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.
Really good to know! Hey, it was the only tool in my tiny toolbox. You are certainly the guru when it comes to optimizing C5 so I will heed your advice.
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.
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.
@mhawke
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...
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...
Interesting. I see you are looking for testers for an alternative to the Zend cache. Perhaps that will show some promise.
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.
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.
Hi Phallanx
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
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