- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Time to first byte slow, but on a fast server
We have a fairly decent dedicated server but we are having issues with the time to first byte being a bit slow (400-700ms) for our magento site. response time for a test php script and a wordpress site on the same domain is alot faster (200ms or less). The host company are saying that the server load is low and its poor coding by the developer ( the developer blames the hosting). I had someone with expertise look at the server setup and the site and bar few tweets to some server settings they agreed with the hosting company that the issue is with poor codeing. He pointed to this guide on how to find bottle necks in the code:
http://www.atwix.com/magento/finding-bottlenecks/
So following that guide I got this result( sorted in order of time and I cut off any under 0.01)
Note it took index.php 559ms to be received for this result
Code Profiler | Time | Cnt | Emalloc | RealMem |
mage | 0.2226 | 1 | 0 | 0 |
mage::dispatch::routers_match | 0.203 | 1 | 0 | 0 |
mage::dispatch::controller::action::cms_index_index | 0.1919 | 1 | 0 | 0 |
mage::dispatch::controller::action::cms_index_index::layout_render | 0.1582 | 1 | 0 | 0 |
frontend/xxxx/default/template/page/homepage.phtml | 0.1487 | 1 | 6,419,984 | 6,553,600 |
mage::dispatch::controller::action::cms_index_index::layout_generate_blocks | 0.0292 | 1 | 6,229,608 | 6,029,312 |
frontend/xxx/default/template/page/html/header.phtml | 0.0176 | 1 | 2,257,304 | 2,359,296 |
frontend/xxx/default/template/page/html/head.phtml | 0.0132 | 1 | 471,352 | 524,288 |
mage::dispatch::controller::action:![]() | 0.0109 | 1 | 1,546,904 | 1,572,864 |
At this point I not sure is these times are normal or not, is there any thing I can compare this too?
Thanks
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: Time to first byte slow, but on a fast server
TTFB needs to be in the 300-500ms range (sub 400ms) without full page cache and 1-2s page loads, you would be surprised even the certified partners don't have this. You lose 40% of visitors above 3s. Every business is different, so you can fix some coding with better hosting and you can fix some hosting with better coding, but to be in the ideal range you need both working in harmony. Very few sites ~5% achieve the ideal ttfb and page loads speeds without a full page cache.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: Time to first byte slow, but on a fast server
Are you using a Full Page Cache? php-fpm with OpCode Caching? Is the Magento Cache and FPC in something like Redis? Are you using Varnish?
Just a few questions about things that can help with TTFB. You can use the Magento Profiler, or try using the AO Profiler as another approach. You can also use something like Xdebug.
Another thing to try is in a dev instance try disabling some modules and see if any of them cause the TTFB to improve drastically. Or change the theme and see if that makes a big difference. Hopefully you can narrow down the culprit.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: Time to first byte slow, but on a fast server
The host specialise on magento setups and is nginx with php-fpm ( not sure about OpCode Caching). I have benched marked other clients on the same server spec and they do not have a TTFB problem.
Full Page Cache is turned on (Zend Cache), but just to see the difference I turned it off and TTFB seemed to improve. So I ran it through googles speed test and its now saying that the server is 0.28 seconds it was about 0.4-0.5 secs before hand ( still not under 0.2 google wants).
I then turned full caching back on and the ttfb is still around 0.28s, so I'm now thoroughly confused that this stage.
Just to put things into perspective, its just the ttfb that annoying me, speed test overall scores are generally good:
google speed test 79/100 (67 for mobile)
Gt Metrix , 86% (B)
YSlow, 73% (C)
The total page load is 2.28s but that includes external stuff like live chat and analytics software (eg crazy egg) that load after the main site loads, so really the site loads in about 1.5sec for the user (with some product pages taking a little longer)
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: Time to first byte slow, but on a fast server
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: Time to first byte slow, but on a fast server
You mentioned Zend Cache, but are you using a Magento Full Page Cache Plugin like Lesti, or a Varnsh based cache such as Turpentine? Once a page is cached by one of these type of extensions, its TTFB should drop considerably.
Also try loading the Magento cache and sessions in something like Redis for faster rendering.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: Time to first byte slow, but on a fast server
Yeah its just the standard Full Page Cache that comes with magento. Is there a particular one you would recommend? I was looking at Turpentine but one of the reviews for it says it does not work past magento 1.7 ( we are on 1.9)
"Also try loading the Magento cache and sessions in something like Redis for faster rendering" I don't know anything about this, can you link to some documentation about it?
Thanks
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: Time to first byte slow, but on a fast server
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Re: Time to first byte slow, but on a fast server
That is the Magento cache, which is not the Full Page Cache. If you are loading the cache from the filesystem instead of memory like Redis, this can happen, yes, as the cache fills up and has more files/data in it. Especially if the hosting account you're on is not truly optimized for I/O and overloads the server a bit (or a lot).
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content