Frequently asked questions

• What do Page Cache warmer do?
• How can I ensure that the full page cache is working?
• What can I do if all pages have "Pending" status?
• How do I check if my pages are cacheable?
• How can I make pages cacheable?
• How can I stop cache flushing?
• How can I control the average system load?
• What do I do if Varnish returns different caches for different user-agents?

What does Page Cache warmer do?

Page Cache Warmer is a crawler (powered by Magento Cron job) which visits uncached pages like users, and adds those pages to the cache. As more pages are in cache, as a whole, the store will operate more quickly.

It can be used by either Magento standard Cache or Varnish, and also works with other cache types (like Redis) without any problem.

How can I ensure that the full page cache is working?

There are a few ways you can check that the full page cache is working correctly on your website:

1. Our extension provides a test page with which you can check that the full page cache is working properly. The link for the testing page is placed on the Pages page of our extension.

   This link leads to a test page that checks the current status of your FPC cache. The test page refreshes every 5 seconds.

   When you visit this page for the first time - you'll see "Checking..." as the status. At the first visit to this page, our extension can't be aware of the FPC cache is working or not.

   After the page refreshes (which happens automatically), the test page will show the current status of the FPC cache. If the full page cache is working properly - you should see a "CACHED" status. If the full page cache not working - you should see a "NOT CACHED" status.

2. How do I check if my pages are cacheable?

3. Check the response time for the page (this check can be used without our extension).

   • Flush the FPC cache on your website.
   • In the new tab of the browser, open the developer tools and there open the "Network" tab.
   • Visit any page of your website and check the response time for the HTML document served from your server (the first line in the "Network tab grid).
   • Refresh the page and check the response time for the HTML document. If the page is cached - the response time should be significantly less then at the first visit. If the page is not cached - the response time for the HTML document will be almost the same as at the first visit.

   Note

   This test can show that the page is not cached even when the FPC cache is working correctly. This may happen if the page you are testing contains uncacheable blocks. It's better to check a few pages with different types as in this case, it will give the correct result for FPC cache. Otherwise, you'll just check the ability to be cached for a particular page.

What can I do if all pages have "Pending" status?

Our extension will work with your store only if Varnish has been configured correctly or if you have switched caching mode to Built-in. This mode is governed by the STORES -> Configuration -> ADVANCED -> System -> Full Page Cache -> Caching Application option, which can have two cases:

Case 1: Varnish:

1. If you have set caching mode to Varnish Cache (Recommended), make sure that Varnish is installed on the server. Use this command to do so: varnishd -V.

   If the result is correct, you should see the Varnish version, as shown below.

2. Set the Show cache status to Yes at the STORES -> Configuration -> Mirasvit Extensions -> Page Cache Warmer -> Debug section. It will show whether your pages are actually cached. If you visit the frontend Category or Product page, you should see a Page Hit message, as shown below:

   

   If the page is not cached, you will see Page Miss, and a list of not cacheable blocks:

   

   In this case, refer to How can I make pages cacheable? section for further actions.

3. If you see Page Miss on most pages without a list of non-cacheable blocks, then switch caching mode to Built-in mode and follow the steps described in the Case 2: Built-in Cache section.

4. If, after all these steps, you see Page Hit on most pages (caching mode set to Built-in Cache), most likely Varnish is not configured to work with Magento. You can verify this using this way.

Case 2: Built-in Cache:

1. If you have set the caching mode to Built-in Cache, then set Show cache status to Yes at the STORES -> Configuration -> Mirasvit Extensions -> Page Cache Warmer -> Debug section.
2. Visit the frontend Category or Product pages of your store to check whether they're actually cached.
3. If you see Page Miss there, you need to fix the caching settings. Refer to How can I make pages cacheable? for further steps.

How do I check if my pages are cacheable?

1. Switch store to Built-in Cache at STORES -> Configuration -> ADVANCED -> System -> Full Page Cache -> Caching Application, and set Show cache status to Yes, as in the previous case.

2. Visit the frontend Category or Product pages of your store to check whether they're actually cached. If the page is cached, you will see a Page Hit message, as shown below:

   

   If you see a Page Miss message with a list of not cached blocks, as shown below

   

   then the pages are not actually cached. Refer to the How can I make pages cacheable? section for further steps.

How can I make pages cacheable?

Variant 1 (from version 1.1.21)

1. Make sure that the page is not cached, using the Show cache status option, set to Yes, and look for the special info box which appears after it:

   

2. Set the Forcibly make pages cacheable option to Yes at Stores -> Configuration -> Mirasvit Extensions -> Page Cache Warmer -> Extended Settings.

3. Purge ALL in Cache Management and revisit the page with Show cache status still enabled. You should see a Page Hit message:

   

Variant 2

1. Make sure that the page is not cached, using the Show cache status option, set to Yes, and look for the special info box which appears after it:

   

2. Connect to your server via SSH, and run the following command:

   grep -r "[your_block_name].*cacheable" * --include="*.xml"

   where [your_block_name] is a block which you can select in the section Not cacheable blocks. It will give you the list of layout files that govern that block.

   Example

   A typical SSH session with layout files listing should look like what you see below. Let the block's name be authorization-link-login

   cd [magento_root_folder]/app/code
   grep -r "authorization-link-login.*cacheable" * --include="*.xml"
   
   cd [magento_root_folder]/app/design
   grep -r "authorization-link-login.*cacheable" * --include="*.xml"

   The output should look like:

   [custom_theme]/Magento_Customer/layout/default.xml  <block class="Magento\Customer\Block\Account\AuthorizationLink" name="authorization-link-login" cacheable="false" template="account/link/authorization.phtml"/>

3. Make sure that the layout does not explicitly forbid caching.

   Open the files which you obtained in the previous step, and search for a block record which should have the following expression in its header:

   name="BLOCK_NAME"

   BLOCK_NAME is the same name as what you saw in the previous step. Remove the attribute cacheable="false" from that record if it exists.

4. Purge ALL in Cache Management and revisit the page with Show cache status still enabled. You should see a Page Hit message:

   

How can I stop cache flushing?

Our Cache Warmer extension does not have the means for cache flushing, and so it can't be the cause of cache flushing.

However, you can see how often your store's cache is flushed using the Fill Rate graph, available at System -> Page Cache Warmer -> Pages.

If flushing is performed too often, you can use logs to see the reasons. To enable this, use the options below at the Stores -> Configuration -> Mirasvit Extensions -> Page Cache Warmer -> Debug section:

• Log tags for cache flushing - is applied to the log each flush schedule.
• Log backtrace for cache flushing - is applied to the log modules which start flushing.

The result will be recorded to the file /var/log/cache-warmer-flush.log.

The most common causes of flushing are reindexing (FPC also flushes cache on reindexing) or re-saving products (FPC also flushes frontend pages, which are associated with a particular product).

Products can also be updated using external WebAPI services, which can trigger cache flushing.

In this and similar cases, you need to configure your system not to save products too often and trigger reindexing not more than once per day.

If it is impossible for some reason, you can disable flushing completely by setting the Forbid cache flushing option to Yes, at Stores ->Configuration -> Mirasvit Extensions -> Page Cache Warmer -> Extended Settings.

How can I control the average system load?

Our extension does not have tools for system load balancing.

However, at SYSTEM->Page Cache Warmer->Jobs, we have a graph Average system load, which will help you identify bottlenecks.

You can also reduce system load by setting a threshold limit for Cache Warmer jobs with the option Don't run the warmer job if the average system load is more than (%) at Stores ->Configuration -> Mirasvit Extensions -> Page Cache Warmer -> Extended Settings section.

If this option is set, whenever warming jobs are started, our extension will check the current load level, and if it is equal to or greater than the entered load percentage, the jobs won't start.

The recommended value for this option is 70 or 80.

What do I do if Varnish returns different caches for different user-agents?

Your Apache or Nginx may return the header Vary:User-Agent. This tells Varnish that distinct user agents should be cached differently. There is a great description of the problem available at https://www.fastly.com/blog/best-practices-using-vary-header .

You can solve it if you add the following to your Apache config:

    Header set Vary "Accept-Encoding"

Or the following to your Varnish config:

    if (req.http.User-Agent ~ "(Mobile|Android|iPhone|iPad)") {
      set req.http.User-Agent = "mobile";
    } else {
      set req.http.User-Agent = "desktop";
    }