Magento – Cm_Cache_Backend_Redis – Suspected config cache invalidation

cachemagento-1.7redis

I have a cluster with 8 webserver nodes and a redis cache instance running on a separate server.

During high load, the throughput on the redis server goes through the roof, approximately 35-40 MB/s (megabytes). I inspected the redis commands with MONITOR on the redis instance and I discovered that there were a disproportionate amount of EVALSHA calls against the redis cache with the config tags.

This means, the web servers were sending data to the redis cache at a pace of 14 MB/s.

If I disable the config cache in the backend, the received bytes counter on the redis server came all the way down to 1 MB/s, which is reasonable.

I suspect that the config cache is getting invalidated somehow.

Have any of you seen anything like this before?

These are my config settings:

<cache>
  <backend>Cm_Cache_Backend_Redis</backend>
  <backend_options>
    <server>10.254.253.1</server> <!-- or absolute path to unix socket -->
    <port>6380</port>
    <persistent></persistent> <!-- Specify unique string to enable persistent connections. E.g.: sess-db0; bugs with phpredis and php-fpm are known: https://github.com/nicolasff/phpredis/issues/70 -->
    <database>0</database> <!-- Redis database number; protection against accidental data loss is improved by not sharing databases -->
    <password></password> <!-- Specify if your Redis server requires authentication -->
    <force_standalone>0</force_standalone>  <!-- 0 for phpredis, 1 for standalone PHP -->
    <connect_retries>2</connect_retries>    <!-- Reduces errors due to random connection failures; a value of 1 will not retry after the first failure -->
    <read_timeout>10</read_timeout>         <!-- Set read timeout duration; phpredis does not currently support setting read timeouts -->
    <automatic_cleaning_factor>0</automatic_cleaning_factor> <!-- Disabled by default -->
    <compress_data>1</compress_data>  <!-- 0-9 for compression level, recommended: 0 or 1 -->
    <compress_tags>1</compress_tags>  <!-- 0-9 for compression level, recommended: 0 or 1 -->
    <compress_threshold>2048</compress_threshold>  <!-- Strings below this size will not be compressed -->
    <compression_lib>snappy</compression_lib> <!-- Supports gzip, lzf, lz4 (as l4z) and snappy -->
    <use_lua>1</use_lua> <!-- Set to 1 if Lua scripts should be used for some operations -->
  </backend_options>
</cache>

Best Answer

Is the first load on the page also slow ? So is the cache also generated again?

I have seen before that there was a special character in the config cache ( copy / paste from Word ) that made the config cache always invalid.

Related Topic