Frequently asked questions

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 be faster.

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

Note

If you use Varnish, please make sure that it is configured correctly. Refer here for more info.

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

Our extension will work with your store only if Varnish is 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. varnishd_v.png

  2. Set 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:

    hit.png

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

    miss_blocks.png

    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 check 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 to 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:

    hit.png

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

    miss_blocks.png

    then the pages are not actually cached. Refer to 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 page is not cached, using the Show cache status option, set to Yes, and look for the special info box which appears after it:

    miss_blocks.png

  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:

    hit.png

Variant 2

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

    miss_blocks.png

  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 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 layout does not forbid caching explicitly.

    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 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:

    hit.png

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.

fill_rate.png

If flushing is performed too often, you can use logs to see its 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/clean.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.

Note

If you have enabled Forbid cache flushing, changes at the Category and Product pages won't apply unless you manually purge the cache from System -> Cache Management, or cache will expire (depends from TTL set in Magento settings).

How can I control the average system load?

Our extension does not have tools for system load balancing.

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

avg_system_load.png

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 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 or greater than entered load percentage, the jobs won't start.

The recommended value for this option is 70 or 80.

What to 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 different user agents should be cached differently. There is a great description of the problem 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";
    }