w3hello.com logo
Home PHP C# C++ Android Java Javascript Python IOS SQL HTML videos Categories
How to reduce the server response time?

Questions and suggestions:

  • Q: 62 milliseconds receiving time is fine. How about you reduce the 1.5 seconds of wait time?
  • S: The wait time is the time it takes the server to compose the page.

-

  • Q: Do you have flat tables enabled?
  • S: Enable flat tables and ensure all customized collection queries still work correctly (the collection queries are converted automatically from EAV resource based queries to Flat resource based queries).

-

  • Q: Do you have caching enabled (with a caching server not file caching)?
  • S: Configure Memcached or Redis or APC as your cache server in local.xml.

-

  • Q: Is your Magento more like an out-of-the-box install with a theme or is the theme and perhaps the logic heavily customized?
  • S: If it's an OOTB theme -- does the theme support proper caching?
  • S: If it's a heavily customized Magento did you take into account the necessary caching support code?

Background info:

Varnish:

Varnish is a full-page cache but Magento is composed of blocks -- blocks expire independently -- full pages need to be rebuilt more often that unrelated blocks.

Varnish (by default) handles static content (JS, CSS, Images etc.). I'm not sure if it also (by default) checks if the html files are using eTags -- i think it does -- so you could start by configuring html pages to use eTag headers and start getting cached (but be careful about the expiration times -- if it's a dynamic page your visitors will see old info you have to decide on which pages this is acceptable.

Memcached (or Redis or APC) and block caching:

If you have Memcached on the server you can configure your local.xml file to start using Memcached for sessions as well as block-caching. But since your Magento is heavily modified your Block classes need to be cacheable -- they need to override getCacheKey method and return a string, that string needs to be different based on the HTML content of the rendered block.

Examples:

  • if you have a block which displays a constant HTML piece the key can be any unique string that you can "calculate" without actually rebuilding/rerendering the block (such as the name you gave the block in your layout.xml).

  • if you have a block which displays "Hi {{username}}!" then the key should be based on either the username or the user_id such as $key = "user_welcome_".$user->getId(); the current user is easily fetched from the session so you don't have to run a database query to fetch it.

  • if you have a block which depends on multiple parameters all of those parameters need to be taken into account when building the cache key and you need to take into account the fact that the parameter information needs to be accessible with as little processing as possible -- if you're fetching info from the DB just to calculate the cache key you might me doing it wrong -- for example a block could differ in content based on the current CMS page_id but you don't need to load the Page object from the DB to know that, you can just process the URL or the $_GET variable and use that info to build the cache key.





© Copyright 2018 w3hello.com Publishing Limited. All rights reserved.