How Magento’s 2-Layer Cache Improves eCommerce Performance
To ensure your customers consistently experience fast page response, your eCommerce website pages should be prebuilt and put into a high-speed page cache. A page caching system will display pages at lightning-fast speeds without any effort needed from your eCommerce platform.
The challenge with any page caching system is maintaining up-to-date content in the cache. When you make changes to your store’s content, any out-of-date pages must be removed and replaced. This can have a negative impact on your site’s performance because after the change, visitors will be requesting pages that don’t exist in the page cache. As a result, page speed slows dramatically and extra processing loads are put on the core system. This affects other processes that depend on core processing power, like checkout.
You can avoid these performance issues with a 2-layer page caching system. A 2-layer cache system manages content transformation so that customers still get high-speed, cached versions of pages while the content changes are happening. With 2-layer cache, you can make changes to content any time without negatively affecting site performance or experience.
Magento Page Caching
Magento Enterprise Edition has a built in full page cache (FPC) mechanism, but it relies on a user to request a page before it caches the page content. Moreover, it doesn’t cache whole pages; instead, it caches content blocks that still have to be merged by Magento every time the user requests the page. This requires Magento to do some work to produce a page, even if all the components that make up the page are cached.
Varnish is a page caching system that caches full pages and delivers them at lightning speed without using Magento to piece them together. Varnish delivers cached pages 10 times faster than Magento so that Magento can focus on other things, like taking orders.
Still, simply adding Varnish doesn’t address the problems associated with making content changes. When a cached page is invalidated, it won’t be reentered into the page cache until a user requests it. Before getting a copy of the page, the unfortunate first user will have to wait for Magento to rebuild the page and put it back into the cache. As a result, page response is slower and greater processing loads are put on the core system because it can take 100x the time and effort to produce a page not already in either FPC or Varnish.
Whenever a change is made, either in the Magento Admin Panel or through a background processes, i.e., a scheduled process or API calls, a substantial portion of cached pages can be tossed out. If this happens at the wrong time, it can have a devastating impact on performance because every page request will suddenly require 100 times more effort to service than it did when the pages were available in a page cache.
Rebuilding pages requires lots of reads from the database. If the cache layer is removed while a large number of users are active on the site, the load on the database will suddenly become tremendous.
Even if the system can handle a sudden influx of requests for uncached pages without toppling over, there will be a significant decrease in site speed until the page cache has been built up again.
This decrease in site speed is often misinterpreted (or overlooked entirely) as general site slowness rather than slowness of specific pages. This leads to a lot of hand wringing over how to make every page a little faster, when in reality the problem isn’t slowness of all web pages, just slowness of specific pages at specific times. Worse yet, the impact on site experience is underrated. It’s much more frustrating to click through a fast site that suddenly hits a series of slow pages than it is to click through a site that’s slower, yet consistently so. Unless you dig into the analytics, which many don’t, you’ll spend a lot of time chasing the wrong cause.
Ideally, customers should never have to wait for a page to be built before seeing it on a browser. To achieve this “always cached” state we use two layers of caching and automated page warming. When content changes are made, the lower cache layer is invalidated and then warmed. Once this is done the upper cache is invalidated. Depending on how much cache is being changed, it can take from a few seconds to a few minutes longer for content changes to appear on the site. But, pages are always in either one cache or the other, so customers continue to get pages delivered at satisfying speeds.
2-Layer Page Cache
With a 2-layer cache, users won’t have to make requests in order to generate pages, and page cache building, i.e., cache warming, can be rate limited so the impact on the database is carefully managed.
For websites with Magento 1 Enterprise, a combination of Magento’s FPC and Varnish is typically used for the 2-layer system. For Magento 2 and Magento Community sites, two layers of Varnish are used to create the 2-layer system. You can’t run both FPC and Varnish in Magento 2; Magento Community doesn’t have a FPC system.
It’s possible to develop a highly sophisticated mechanism that targets very narrow segments of cache to cycle through. However, this requires you to manage a complex relationship with the Magento content change mechanisms. If your site handles very high traffic and frequent content changes, it’s worth developing this level of sophistication. In general, everyone can benefit from a basic 2-layer system, which isn’t difficult or expensive to create.
Basic Page Cycling
The following is a description of a basic 2-layer system that uses FPC and Varnish, plus a simple page cycling system to warm the cache.
Full Cache Recycling Sequence
Built-in cache invalidation is disengaged and a new button is introduced in the admin panel’s cache management section. Clicking the button triggers a controlled full cycling of the 2-layer cache:
1. Warming of the top cache (Varnish) to ensure the most commonly accessed pages exist in the top cache layer.
2. Flushing of the bottom cache (FPC).
3. Warming of the bottom cache to ensure new versions of the most commonly accessed pages are added to the bottom cache layer. (This process is carefully rate limited.)
4. Flushing of the top cache so all the new changes are revealed.
This system relies on user requests to generate top cache pages. It can handle the brief spike in processing power required to build the top cache, provided the commonly accessed pages are available in the bottom cache.
Commonly Requested Pages
Commonly requested pages are a combination of three perspectives.
1. Primary site maps as defined in the Magento Admin Panel.
2. Pages that are one or two clicks away from the pages in the primary site map.
3. Manually entered page URLs.
Commonly requested pages are a key subset of pages that are warmed, i.e., automatically created and placed in the page cache. The number of page permutations made possible by the size and complexity of a website’s product line may make it impractical to prebuild every page. You can roughly estimate the number of page permutations by multiplying stores × categories × subcategories × SKUs × product attributes.
This basic design of page cycling will cover enough of the most commonly requested pages, which will help you avoid performance problems that would otherwise result from unmanaged content change.
Want to learn more about eCommerce site speed and performance? Read our free white paper, How to Measure Site Speed in eCommerce. [no registration required]
Stephen Chinn is the director of application hosting services at LYONSCG. Since joining the company in 2010, he’s built a hosting service for both cloud and dedicated physical servers, created a data center, and developed a US-based operations and support center with 24/7 emergency response. He holds a BS in speech communications from Southern Illinois University in Carbondale.
LYONSCG is a Gold Partner in the Magento partner ecosystem.
