3

I am trying to reduce my time to first byte on a magento 1.8.1 site.

  1. Magento is running on an openVZ 4g vps server all on its own
  2. I have LESTI::FPC http://gordonlesti.com/lestifpc extension which works great, I have even tried removing the dynamic and lazy blocks but see no performance difference
  3. Redis is setup and working for fpc cache and session caching
  4. I have just one colour swatch extension installed
  5. The time to first byte is the same for any page on the website once the page has been cached give or take 50ms from a blank homepage to product category page with layered navigation
  6. I have 4 websites setup and just 10 products, 3 users
  7. mysqltuner.pl has been used to optimise the mysql server
  8. I have allocated a good amount of ram to php and using 'top' I can see the resource usage is never over 50% when performing the heaviest backed functions in magento like re-indexing.

All the standard client side stuff has been done such as reducing request and file life limits and such, here I am asking about server side performance.

ttfb

above is chrome showing the 400ms wait for the first byte

So, I can't understand why a this server, which is purely hosting 1 magento website takes 400ms to return full cached homepage which is a tiny 10025 bytes html file ? btw, with the standard magento cache the ttfb is 750ms on the homepage as of now.

As mentioned I am using redis for the cache so I believe the cache is stored in the memory in that case and would be the fastest option, it seems like overkill at this time but should be the fastest option but then using the standard file/disk based magento cache gives the same results.

(I ran a mysql query log when viewing the cached homepage and saw just 1 mysql query so to me that rules our mysql being the issue) but maybe not?

I have read a number of similar posts about similar issued with people using varnish and often people reply about the performance of magento, but once the page is cached, magento and mysql doesn't come into it does it? apart any dynamic blocks which are not cached? (as mentioned I tried disabling dynamic and lazy blocks in the fpc extension i am using and saw I tiny improvement, maybe 20ms)

All I can think is it is server hardware limitation? but surely 4g is enough to run this? some people slate openvz because you don't have truly allocated resources, but like i said, using top command the resources are not being strained.

The blank home page is actually 50ms slower to return the first byte than a category with 10 products...

So can anyone please give me some advice? to me it seems to boil down to an issue of the server returning the cached files slowly rather than magento seeing as the pages are fully cached.

Thanks very much for any help.

1
  • Please summarize your HTTP server configurations and how you are dispatching requests to PHP.
    – parhamr
    Aug 6, 2014 at 22:21

3 Answers 3

1

i guess you need to RTFM first.
http://gordonlesti.com/how-does-lesti-fpc-work/


a quote from its author:

Lesti::Fpc has an other workflow. I wanted a full page cache with the same flexibility of Magento. That means a little bit more loading time than other caches.

btw you have 3 errors on your page, and this is a browser who slows you down anyway, not magento cache.

but if you need to see some real speed - use Turpentine Varnish Cache...

3
  • Hi, looking at the work flow, without any dynamic blocks, lesti fpc just returns the cached page, and as mentioned I removed the dynamic block settings from lest and saw no difference in the ttfb. The errors are from merging the java files within magento, which I did to try and prevent lots of comments on client side tips to speed things up, but I am asking for server side advise, I dont see how java script errors can effect a servers ttfb. I dont know what you mean by " this is a browser who slows you down anyway, not magento cache." ?
    – renton84uk
    May 19, 2014 at 19:37
  • I have been looking at Turpentine Varnish Cache, I suppose I will have to try that and see if it improves things.
    – renton84uk
    May 19, 2014 at 19:39
  • When you look at the demo sites for Turpentine Varnish Cache github.com/nexcess/magento-turpentine/wiki/Demo-Sites the American Legacy Fishing one which is the closest spec server to mine has similar ttfb speeds. the other demos which on are much more powerfull servers have super fast speeds, less than 50ms ttfb speeds, so even though my sever is no where near maxed load, is it purley a need for more power to get faster ttfb times? thats what I am starting to think.
    – renton84uk
    May 19, 2014 at 19:49
0

Probably the biggest issue will be the limited cache of Magento. The speed should increase by using a Full Page Cache extension. I'm a big fan of Brim FPC but any other will do.

Second I would focus the tests on catalog pages. The homepage is one of the slowest pages I've experienced.

5
  • Hi, I did already explain I am using a full page cache extension, which was kind of the main focus of my question, the fact it is fully cached and the server is still slow to return the page
    – renton84uk
    May 19, 2014 at 14:33
  • @renton84uk time to first byte can have numerous causes. It doesn't need to be a software issue. Magento needs some proper performance tweaking regarding MySQL, Apache etc. So make sure you also follow the whitepaper on this aspect magentocommerce.com/whitepaper.
    – Tim Hofman
    May 19, 2014 at 15:55
  • @renton84uk ah sorry, my mistake
    – Sander Mangel
    May 19, 2014 at 17:37
  • @Tim Hofman, thanks but if the page is fully cached, this is more of a question about the server speed sending out a cached html file rather than magento performance. or maybe I am wrong? if so please someone explain how magento can effect the speed of returning a fully caches page? I can see the html file in the cache directory if I set magento and Lestic FPC to cache to disk, so the file is already there on the server, it doesnt need to be created, just served up to the user requesting it. am I incorrect in my thinking?
    – renton84uk
    May 19, 2014 at 20:00
  • Except fpc just puts all the problems under the carpet which Google and visitor checkout sees through, so on the surface it all looks good, but underneath you are having to put between 2-5x or 5-10x more effort to rank your pages, not including the stale content problem with fpc (currencies etc). Then you also need to understand that top enterprise sites target 1-2s page loads with dynamic content. So what does this come down to, hosting. We just put a company on some third party hosting with sub-second non-fpc loads, had to add a crawl delay for Google - and reduces the problems, always good.
    – user2935
    May 22, 2014 at 15:26
0

With our FPC, http://ecommerce.brimllc.com/performance/full-page-cache-magento.html, you should be able to get your time to first byte much closer to 100ms, especially when you enable our Level1 cache option. And most of that time is just time over the wire. When testing locally, you can get 10-30 ms ttfb. The actual numbers are dependent on the environment and resources available.

The Level1 cache won't work for every site, but with what we have seen on yours, it should work fine. It intercepts requests very early on for visitors without anything in their cart and serves the page. If the customer is logged in or has something in their cart, it falls back to the standard cache where we have full support for hole punching via our custom block updates.

We love Redis and it's great for what it's designed for, but it might not be the right solution for every site. Redis is accessed over the network stack which may be slower than say the APC object cache, which doesn't use the network at all. If you do continue to use Redis make sure you also have the PHP Redis extension installed and are not just relying on the pure PHP library as the pure PHP one is much much slower from our testing.

Also, if you have more than just a few products, we generally don't recommend a memory based cache as FPCs can consume a lot of storage space. Thus, if you don't have a lot of memory and you have a good size catalog disk, a disk based backend can actually be a better option for the FPC. However your standard Magento cache backend should be memory based whenever possible.

In our view, Varnish is great, but might not be the right solution for every site. You really need a ton of traffic and servers to make Varnish worthwhile. Even when using Varnish, you still have to do a request to Magento to generate the dynamic user specific content via ESI or an Ajax request so you still have the Magento load overhead.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.