kealan Posted September 23, 2015 Share Posted September 23, 2015 Hello CC Forum, I am having an issue with our sites loading speeds and I am at a loss as to what is causing it. The page loading speed for the homepage is in and around the 5-10 second mark which is horrid. There are a few areas regards the content / external calls itself we are working on and we are confident we can get it down to 2-3 seconds, however there is one variable we cannot get around at the moment. The initial first byte time on page load can vary from 1 - 4 seconds, so I suggested to my hosting provider its time to move it over to a vps, interestingly the hosting provider advised that a VPS wont cure the problem I am having with the site that its most likely a problem caused by the .htaccess file /caching/old plugins. After some disagreement we both ran tests and regardless of what is in the .htaccess file the issue persists, in a final test to prove my provider wrong i tested a html site on same server and to my dismay the issue did not occur on the html site the whole thing loaded in under a second. We use memcache and minimal plugins, braintree payments plugin is the only 3rd party. Any thoughts on what might cause this initial delay? is anyone else having this issue with cc6?site - mcsoutdoorstore.ie.htaccess file attached + speed test Thanks in advance to anyone who read this farK .htaccess Quote Link to comment Share on other sites More sharing options...
havenswift-hosting Posted September 23, 2015 Share Posted September 23, 2015 There is nothing in the .htaccess file that would or could cause that and it seems a strange statement for your hosting provider to make and you have disproved that anyway.However trying to compare the load times of a very heavy CMS based homepage with a simple html file isnt comparing like for like - your homepage is pretty big with images that on first visit are not cached - second and subsequent visits are much quicker although still not as quick as they could be.It will be difficult for anyone to give exact answers without a lot more in depth detail but then I would have thought your hosting company would have been able to analyse that and tell you more.Ian Quote Link to comment Share on other sites More sharing options...
ayz1 Posted September 23, 2015 Share Posted September 23, 2015 Just looked at your site, seems fine to me. Quote Link to comment Share on other sites More sharing options...
bsmither Posted September 23, 2015 Share Posted September 23, 2015 A waterfall from the browser/client's point of view has a lot of merit. But be aware that this environment includes a lot of plumbing outside of your web server's environment - between that datacenter:* and you* and the service that you pasted the above screen shot from* and any other visitor to your siteI will state that what seems to be the biggest time-hog is the Smarty template rendering engine. I can crash PHP just before Smarty is to make the final rendering and the response of the 500 Internal Server Error is near instantaneous. On the other hand, a completed page on my local server as delivered to my browser is still from 1 to 4 seconds. (Disclaimer: I typically do not have caching enabled. So the database accesses are in the hundreds. But the SQL cache gets cleared way too often anyway.)Please enable CubeCart's debugging (admin, Store Settings, Advanced tab, enable debugging and enter your IP address (www.whatismyip.com) in the adjacent field so that only you see the debug output). At the bottom is the time it took from start to some time just before absolute finish. This includes only the time PHP is running and also includes the time it takes for database communications.I have XDEBUG installed in my local PHP, which has a Profiler feature called CacheGrind. Triggering a cachegrind burns a lot of time, but the report reflects only the time it takes for each PHP function to execute. I do not yet have the expertise to understand the display that a cachegrind output interpreter shows, but the cachegrind promises to show where the bottlenecks are. Quote Link to comment Share on other sites More sharing options...
bsmither Posted September 24, 2015 Share Posted September 24, 2015 I just learned that wanting a Smarty {debug} console on a template adds 50% time spent to deliver the first byte to the web browser. Whew! Quote Link to comment Share on other sites More sharing options...
kealan Posted September 24, 2015 Author Share Posted September 24, 2015 (edited) Many thanks for the replies I appreciate my initial question was somewhat vague! After enabling the debugging and reviewing the export I definitely seem to be having some unexpected issues, and annoyingly the issue appears to be around caching so my hosting provider was correct. It appears although memcached* is enabled on the server I still seem to be having some problems actually writing some of the cache data back to the host, which appears to be creating a lot of hangups which I can only assume is causing some issues with load times. I will raise this back to my provider but I have also included the output below, it appears that mysql data is being cached but nothing utilising memcache. Would appreciate any steer here if there is anything else my side that might be addressable or if I am missing anything else here. debuglog.txt Edited September 24, 2015 by kealan *memcached not memcache Quote Link to comment Share on other sites More sharing options...
kealan Posted September 24, 2015 Author Share Posted September 24, 2015 After troubleshooting with my hosting provider for most of the day we managed to resolve some of the 'open_basedir restriction in effect' errors which was server side but could not resolve the bulk of the debug errors.After doing some research I found that cubecart will be happy running apc, so i disabled memcached and enabled apc at the server level, Cubecart auto-detected the changes which was nice! my page load times are now sub 4 second. I am still not happy with the the fact that the initial call of the homepage is still taking around one full second but as Brian pointed out the smarty system needs a bit of time to come to life. Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted September 25, 2015 Share Posted September 25, 2015 (edited) I understand so little of this conversation I have to ask - is this thread ready to be marked Resolved or not?? From later comments I'm going to assume this is going to be an on-going conversation, so I'll leave it as is. Edited September 27, 2015 by Dirty Butter Quote Link to comment Share on other sites More sharing options...
bondimedical Posted September 26, 2015 Share Posted September 26, 2015 There is definitely some problem. As you can see from your own results getting the first byte is very slow. Have you tried using a CDN? Quote Link to comment Share on other sites More sharing options...
havenswift-hosting Posted September 26, 2015 Share Posted September 26, 2015 After troubleshooting with my hosting provider for most of the day we managed to resolve some of the 'open_basedir restriction in effect' errors which was server side but could not resolve the bulk of the debug errors.After doing some research I found that cubecart will be happy running apc, so i disabled memcached and enabled apc at the server level, Cubecart auto-detected the changes which was nice! my page load times are now sub 4 second. I am still not happy with the the fact that the initial call of the homepage is still taking around one full second but as Brian pointed out the smarty system needs a bit of time to come to life. Memcached should generally be quicker than APC but if it isnt configured correctly on your hosting server then that isnt much help but to get the best performance out of APC it does need more tuning and configuration.Time to first byte can be caused by any number of things including poor or slow DNS servers but would need more detailed analysis to determine what the cause is in your case. A CDN would also help, especially if your customer base is distributed worldwide, as your homepage images are reasonably big.Brian pointed out that the Smarty debug added a lot of overhead rather than the use of Smarty itself although it does add someIan Quote Link to comment Share on other sites More sharing options...
kealan Posted September 26, 2015 Author Share Posted September 26, 2015 Thanks all for your replies. I will try and address all points. Resolved? My load times have stabilised but are still concerns over the first byte time of nearly a second. http://www.webpagetest.org/result/150926_FY_V6J/1/details/DNS . I considered this but there are a number of other websites with and without a CMS on the same hosting server /dns server that score fine on first byte time, though none on ssl. Memcache . I would suspect this is serverside as my hosting provider was able to resolve some but not all of the issues, APC will have to suffice here. I have signed up and enabled cloudflare over the last week via the cpanel so I have only made minor adjustments to the caching config on cloudflare itself, only 1 cached item served so far despite having nearly 2000 hits over that same period. Not sure if that's a discussion unto itself. Quote Link to comment Share on other sites More sharing options...
bsmither Posted September 26, 2015 Share Posted September 26, 2015 You can make a comparison for your site with and without CubeCart by requesting a PHP file that has nothing but the command to respond with the PHP configuration.You can find an example of this command in the /setup/info.php file that ships with CubeCart (but after installation, CubeCart will attempt to delete the /setup/ folder).Comparing the first byte time to get this info page versus the time to get the CubeCart homepage (assuming no external caching) should indicate how much additional time CubeCart is consuming. The common time is how much the server (request and response transit times, web server, PHP startup, et al) is consuming. Quote Link to comment Share on other sites More sharing options...
ayz1 Posted September 27, 2015 Share Posted September 27, 2015 I've looked at the waterfall chart for site - mcsoutdoorstore.ie and the time spent waiting (purple section) which is the period between sending and receiving seems to take a while, much longer then mine when I have compared them. Mine is blocking for longer but have no idea what that is doing or why! Something for me to look into.Very interesting topic. Quote Link to comment Share on other sites More sharing options...
bsmither Posted September 27, 2015 Share Posted September 27, 2015 "Blocking", to me, is when the browser has maxed out it's connections to that domain, either from it's own internal limiters ("good browsing" etiquette), or from the operating system's limit on TCP channels. A dozen years ago (several eons in computer-time), one could adjust a setting that allowed each limiter to mave more channels open.The image above suggests that your browser can open at least 13 channels - that is, make at least 13 simultaneous requests for images or whatever.Still, they all must flow through the one single internet pipe that represents your home connection to the Internet. Quote Link to comment Share on other sites More sharing options...
kealan Posted September 28, 2015 Author Share Posted September 28, 2015 Hi All,Here is the results from a simple info.php file on the same server - No issues with First Byte time http://tools.pingdom.com/fpt/#!/b4tTpo/https://mcsoutdoorstore.ie/info.php http://www.webpagetest.org/result/150928_W9_K10/1/details/the info file contained redirects so I have also run the tests on a blank html file on the same server http://www.webpagetest.org/result/150928_54_KAR/ http://tools.pingdom.com/fpt/#!/bk5ga/https://mcsoutdoorstore.ie/test.htmlAll tests are coming back in the sub second region My overall homepage loading speed is from 5-7 seconds as per web page test http://www.webpagetest.org/result/150928_AB_KTR/1/details/But is below 2 seconds via pingdom but this seems very unrealistic / gtmetrix is down at the moment http://tools.pingdom.com/fpt/#!/bDgPTD/https://mcsoutdoorstore.ieBut a visit to the site will clearly show its not loading anywhere near that, its still 5-7.With reference to the number of GET requests / Blocking there also may be another factor in play, though this could be waffle as I am on the edge of my experience here! as part of the initial optimisation of the site we deferred the loading of any specific render blocking scripts until after the initial resources are loaded. We are going to try and asynchronously load some of this content and see if we can reduce the overall times, although this will actually usually score us lower on google page speed test. Though this may be pointless if we are maxing out the tcp connections themselves. Quote Link to comment Share on other sites More sharing options...
kealan Posted October 8, 2015 Author Share Posted October 8, 2015 (edited) Hi all, Just said I would drop a quick update to inform of the progress I have made here with overall site speeds. After much head scratching and testing trying to eliminate the lag with first byte time I just bit the bullet and loaded the site into cloudflare. So far the results have been pretty amazing load times down to 3 second mark which is where I believed it should have been.https://gtmetrix.com/reports/mcsoutdoorstore.ie/bujB8wkUThe only issues we have encountered so far is that cloudflare is having issues serving content that itself is served via a CDN. So plugins like the facebook like and comment section which is CDN served had to go, they were working but were causing the page to 'melt' for the lack of a better word until 100% loaded. When users scrolled down they areas where this content was due to be loaded the page started scrolling indefinitely leaving streaking white boxes and then snapping back on fully loaded. We also had to set the cloudflare caching to non-aggressive as it was causing the basket and cookie policy reminder to reset when the homepage was called. But overall a huge performance and SEO boost for 0 cost, no need to move to a VPS for the moment, I hope this helps others out there. K Edited October 8, 2015 by kealan typo Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted October 9, 2015 Share Posted October 9, 2015 Thanks for the feedback, kealan! And glad you found a solution that may help many others as well. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.