400ms time to first byte ( ttfb ) on a fully cached magento 0.01mb page on 4g vps server, how can I reduce it?

Question

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.

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.

Answer 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...

Answer 2

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.

Answer 3

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.