Hey Colin !

Firstly i wanna thank you for your awesome work on creating this new cache type.

Sometimes have got this error poping, particulary when traffic is high on the website :

An error occurred connecting to Redis.

Trace:
prod/.modman/Cm_Cache_Backend_Redis/lib/Credis/Client.php(278): Credis_Client->connect()
prod/.modman/Cm_Cache_Backend_Redis/Cm/Cache/Backend/Redis.php(128): Credis_Client->_call('hGet', Array)
prod/.modman/Cm_Cache_Backend_Redis/Cm/Cache/Backend/Redis.php(128): Credis_Client->hGet('zc:k:cc4_CORE_C...', 'd')
prod/lib/Zend/Cache/Core.php(303): Cm_Cache_Backend_Redis->load('cc4_CORE_CACHE...', false)
prod/app/code/local/Mage/Core/Model/Cache.php(330): Zend_Cache_Core->load('CORE_CACHE_OPTI...')

for only 100 user connected on redis server.

What's your opinion ?

Do you think this is somethink related with server configuration ? Have you ever experimented something like that ?

Hi, I have been using this backend in my production server quite successfully for the past 1 month.
The only problem I have spotted so far is that after a few days without restarting redis (I do not use persistence, so restart=flush), some cache keys disappear from their tag's list, which leads to them not being deleted upon a cache clean by tags.

So far, I have not managed to reproduce this behavior on purpose, it seems to be quite random.
I am thinking of 2 scenarios:

1. The gc script is not working properly (I am running it every 3 hours)
2. While a tag clean is being executed, another request is inserting new keys to the same tag and something goes wrong (no locking?)

I have not yet thoroughly reviewed the code, so I do not have a complete view of how (or if) locking is implemented for writes/flushes, will do so as soon as possible.

In the meanwhile, has this behavior been spotted before?

snip of 'app/etc/local.xml'

<cache>
  <backend>Cm_Cache_Backend_Redis</backend>
  <backend_options>
    <server><![CDATA[/tmp/redis6380.sock]]></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>2</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>1</force_standalone>  <!-- 0 for phpredis, 1 for standalone PHP -->
    <connect_retries>1</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>20480</compress_threshold>  <!-- Strings below this size will not be compressed -->
    <compression_lib>gzip</compression_lib> <!-- Supports gzip, lzf, lz4 (as l4z) and snappy -->
    <use_lua>0</use_lua> <!-- Set to 1 if Lua scripts should be used for some operations -->
  </backend_options>
</cache>

Redis is running and listening on unix socket:

port 0
 unixsocket /tmp/redis6380.sock

However, socket connection works fine with redis itself:

redis-benchmark -q -n 10000 -s /tmp/redis6380.sock
PING_INLINE: 54945.05 requests per second
PING_BULK: 70422.53 requests per second
SET: 81300.81 requests per second
GET: 72463.77 requests per second
INCR: 66666.66 requests per second
LPUSH: 60606.06 requests per second
LPOP: 59171.60 requests per second
SADD: 63694.27 requests per second
SPOP: 81300.81 requests per second
LPUSH (needed to benchmark LRANGE): 88495.58 requests per second
LRANGE_100 (first 100 elements): 38461.54 requests per second
LRANGE_300 (first 300 elements): 12091.90 requests per second
LRANGE_500 (first 450 elements): 5592.84 requests per second
LRANGE_600 (first 600 elements): 9737.10 requests per second
MSET (10 keys): 54945.05 requests per second

Magento log contains following:

ERR (3): Notice: Undefined index: port  in /home/username/public_html/lib/Cm/Cache/Backend/Redis.php on line 96

and

a:4:{i:0;s:44:"Connection to Redis failed after 2 failures.";i:1;s:1473:"#0 /home/username/public_html/lib/Credis/Client.php(362): Credis_Client->connect() 

If I missed something or misunderstood, please correct me. loca.xml setting - specifying the socket with no CDATA results same.

Thanks in advance for help and btw great thing 👍

I installed a module for caching using Redis: https://github.com/colinmollenhour/Cm_Cache_Backend_Redis.
This now works as the cache storage. I can see that the Magento website makes requests to the Redis server on database 2.
My cache config looks like:
server:10.46.0.130
port:6379
database:2
force_standalone:1

I then changed the cache storage for Tinybrick's Lightspeed to also use this module as described at:
http://www.drewgillson.com/blog/customize-tinybricks-lightspeed-for-use-with-redis/

My Lightspeed cache config looks like:
server:10.46.0.130
port:6379
database:3
force_standalone:1

Once I do this I start getting an error on the index.php home page:
Connection to 10.46.0.130:6379 failed: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
(10060)

Trace:
#0 E:\xampp\htdocs\getit\src\getitstores\lib\Credis\Client.php(323): Credis_Client->connect()
#1 E:\xampp\htdocs\getit\src\getitstores\lib\Credis\Client.php(316): Credis_Client->__call('select', Array)
#2 E:\xampp\htdocs\getit\src\getitstores\lib\Cm\Cache\Backend\Redis.php(83): Credis_Client->select(3)
#3 E:\xampp\htdocs\getit\src\getitstores\app\code\community\TinyBrick\LightSpeed\Model\Server\Redis.php(21): Cm_Cache_Backend_Redis->__construct(Array)
#4 E:\xampp\htdocs\getit\src\getitstores\app\code\community\TinyBrick\LightSpeed\Model\Server\Redis.php(27): TinyBrick_LightSpeed_Model_Server_Redis->getServer()

I think the reason is:
App::_initCache obtains a cache object of type Cm_Cache_Backend_Redis. This is for the core Magento caching.

Later, Lightspeed comes in and creates its own Credis client which tries to open a TCP connection that is already open.

Is it safe to use the same database for Core cache and Lightspeed cache?
And instead of creating a new Credis client for Lightspeed use the cache created by core Magento?

The backend works perfectly for caching, and flushing also works. But i get theerror above if i press the "flush magento cache" button in the admin page. If i refresh it, everything is fine, but the first error is a bit annoying. Pulled from master 4 days ago

I’m trying to add debug logging to this module, but I consistently see segfaults when calling Mage::log('test', Zend_Log::DEBUG, self::LOG_FILE); from within these functions:

• load() after line 168
• _decodeData() after line 701

The logger works in these functions:

• __construct()
• test()
• save()
• remove()
• clean()
• _encodeData()
• setDirectives()

Environment:

• php-fpm, 5.3.10-1ubuntu3.7, Suhosin Patch 0.9.10
• nginx 1.2.6
• Redis 2.6.11
• Ubuntu 12.04 LTS 64-bit

My plan is to strace the failure, but I’d also appreciate your insight.

I saw you popped into this issue with PHPRedis here:
phpredis/phpredis#70

It might completely reside with them but thought I would post here in case you had found a solution outside of PHPRedis to handle this with Cm_Cache_Backend_Redis.

The only new thing I saw of note in that thread was within the past few weeks:

"I encountered this same error message. Using the tip from @redzarf - I did some research and found that some of the strings we were trying to store are indeed more than 64KB (65,536 Characters).

As a quick solution I started gzip'ing data before storing it in redis. Havn't seen the "read error on connection" error since."

Here are some of my dump(s) when this hits:

Error:
read error on connection

Trace:
#0 /app/code/community/Cm/Cache/Backend/Redis.php(128): Credis_Client->__call('hGet', Array)
#1 /app/code/community/Cm/Cache/Backend/Redis.php(128): Credis_Client->hGet('zc:k:139_TRANSL...', 'd')
#2 /lib/Zend/Cache/Core.php(303): Cm_Cache_Backend_Redis->load('139_TRANSLATE_E...', false)
#3 /app/code/core/Mage/Core/Model/Cache.php(351): Zend_Cache_Core->load('TRANSLATE_EN_US...')
#4 /app/code/core/Mage/Core/Model/App.php(1126): Mage_Core_Model_Cache->load('translate_en_US...')
#5 /app/code/core/Mage/Core/Model/Translate.php(521): Mage_Core_Model_App->loadCache('translate_en_US...')
#6 /app/code/core/Mage/Core/Model/Translate.php(121): Mage_Core_Model_Translate->_loadCache()
#7 /app/code/core/Mage/Core/Model/App/Area.php(146): Mage_Core_Model_Translate->init('frontend')
#8 /app/code/core/Mage/Core/Model/App/Area.php(121): Mage_Core_Model_App_Area->_initTranslate()
#9 /app/code/core/Mage/Core/Model/App/Area.php(93): Mage_Core_Model_App_Area->_loadPart('translate')
#10 /app/code/core/Mage/Core/Model/App.php(768): Mage_Core_Model_App_Area->load()
#11 /app/code/core/Mage/Core/Controller/Varien/Action.php(493): Mage_Core_Model_App->loadArea('frontend')
#12 /app/code/core/Mage/Core/Controller/Front/Action.php(59): Mage_Core_Controller_Varien_Action->preDispatch()
#13 /app/code/core/Mage/Core/Controller/Varien/Action.php(409): Mage_Core_Controller_Front_Action->preDispatch()
#14 /app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(250): Mage_Core_Controller_Varien_Action->dispatch('view')
#15 /app/code/core/Mage/Core/Controller/Varien/Front.php(176): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#16 /app/code/core/Mage/Core/Model/App.php(349): Mage_Core_Controller_Varien_Front->dispatch()
#17 /app/Mage.php(640): Mage_Core_Model_App->run(Array)
#18 /index.php(83): Mage::run('', 'store')
#19 {main}

Error:
read error on connection

Trace:
#0 /app/code/community/Cm/Cache/Backend/Redis.php(128): Credis_Client->__call('hGet', Array)
#1 /app/code/community/Cm/Cache/Backend/Redis.php(128): Credis_Client->hGet('zc:k:139_DB_PDO...', 'd')
#2 /lib/Zend/Cache/Core.php(303): Cm_Cache_Backend_Redis->load('139_DB_PDO_MYSQ...', false)
#3 /lib/Varien/Db/Adapter/Pdo/Mysql.php(1442): Zend_Cache_Core->load('DB_PDO_MYSQL_DD...')
#4 /lib/Varien/Db/Adapter/Pdo/Mysql.php(1564): Varien_Db_Adapter_Pdo_Mysql->loadDdlCache('eav_attribute', 1)
#5 /app/code/core/Mage/Catalog/Model/Resource/Product/Attribute/Collection.php(55): Varien_Db_Adapter_Pdo_Mysql->describeTable('eav_attribute')
#6 /app/code/core/Mage/Core/Model/Resource/Db/Collection/Abstract.php(135): Mage_Catalog_Model_Resource_Product_Attribute_Collection->_initSelect()
#7 /app/code/core/Mage/Core/Model/Config.php(1350): Mage_Core_Model_Resource_Db_Collection_Abstract->__construct(Array)
#8 /app/code/core/Mage/Core/Model/Config.php(1386): Mage_Core_Model_Config->getModelInstance('catalog_resourc...', Array)
#9 /app/Mage.php(460): Mage_Core_Model_Config->getResourceModelInstance('catalog/product...', Array)
#10 /app/code/core/Mage/Catalog/Model/Layer.php(226): Mage::getResourceModel('catalog/product...')
#11 /app/code/core/Mage/Catalog/Block/Layer/View.php(163): Mage_Catalog_Model_Layer->getFilterableAttributes()
#12 /app/code/local/Lp/Catalog/Block/Layer/View.php(121): Mage_Catalog_Block_Layer_View->_getFilterableAttributes()
#13 /app/code/core/Mage/Core/Block/Abstract.php(238): Lp_Catalog_Block_Layer_View->_prepareLayout()
#14 /app/code/core/Mage/Core/Model/Layout.php(430): Mage_Core_Block_Abstract->setLayout(Object(Mage_Core_Model_Layout))
#15 /app/code/core/Mage/Core/Model/Layout.php(446): Mage_Core_Model_Layout->createBlock('catalog/layer_v...', 'catalog.leftnav')
#16 /app/code/core/Mage/Core/Model/Layout.php(238): Mage_Core_Model_Layout->addBlock('catalog/layer_v...', 'catalog.leftnav')
#17 /app/code/core/Mage/Core/Model/Layout.php(204): Mage_Core_Model_Layout->_generateBlock(Object(Mage_Core_Model_Layout_Element), Object(Mage_Core_Model_Layout_Element))
#18 /app/code/core/Mage/Core/Model/Layout.php(209): Mage_Core_Model_Layout->generateBlocks(Object(Mage_Core_Model_Layout_Element))
#19 /app/code/core/Mage/Core/Controller/Varien/Action.php(345): Mage_Core_Model_Layout->generateBlocks()
#20 /app/code/core/Mage/Catalog/controllers/CategoryController.php(150): Mage_Core_Controller_Varien_Action->generateLayoutBlocks()
#21 /app/code/core/Mage/Core/Controller/Varien/Action.php(420): Mage_Catalog_CategoryController->viewAction()
#22 /app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(250): Mage_Core_Controller_Varien_Action->dispatch('view')
#23 /app/code/core/Mage/Core/Controller/Varien/Front.php(176): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#24 /app/code/core/Mage/Core/Model/App.php(349): Mage_Core_Controller_Varien_Front->dispatch()
#25 /app/Mage.php(640): Mage_Core_Model_App->run(Array)
#26 /index.php(83): Mage::run('', 'store')
#27 {main}

Seems like a great class, but sometimes the same server setup is used for multiple applications, which means that in it's current form the class is not usable. It would be great to have support for a key/tag prefix.

I. e. so that these prefixes:

const PREFIX_KEY      = 'zc:k:';
const PREFIX_TAG_IDS  = 'zc:ti:';

would actually be prefixed some an optional value fetched from configuration, e.g. named "prefix".

Hello,

We have had Redis running just fine for quite a few weeks and suddenly started getting this error:

a:4:{i:0;s:38:"An error occurred connecting to Redis.";i:1;s:1627:"#0 /var/www/vhosts/vbc/httpdocs/lib/Credis/Client.php(278): Credis_Client->connect()
#1 /var/www/vhosts/vbc/httpdocs/app/code/community/Cm/Cache/Backend/Redis.php(128): Credis_Client->__call('hGet', Array)
#2 /var/www/vhosts/vbc/httpdocs/app/code/community/Cm/Cache/Backend/Redis.php(128): Credis_Client->hGet('zc:k:c2e_REQEST...', 'd')
#3 /var/www/vhosts/vbc/httpdocs/lib/Zend/Cache/Core.php(303): Cm_Cache_Backend_Redis->load('c2e_REQEST_824F...', false)
#4 /var/www/vhosts/vbc/httpdocs/app/code/core/Mage/Core/Model/Cache.php(329): Zend_Cache_Core->load('REQEST_824F9681...')
#5 /var/www/vhosts/vbc/httpdocs/app/code/core/Enterprise/PageCache/Model/Processor.php(519): Mage_Core_Model_Cache->load('REQEST_824f9681...')
#6 /var/www/vhosts/vbc/httpdocs/app/code/core/Enterprise/PageCache/Model/Processor.php(460): Enterprise_PageCache_Model_Processor->_loadMetadata()
#7 /var/www/vhosts/vbc/httpdocs/app/code/core/Enterprise/PageCache/Model/Processor.php(169): Enterprise_PageCache_Model_Processor->getMetadata('cache_subproces...')
#8 /var/www/vhosts/vbc/httpdocs/app/code/core/Mage/Core/Model/Cache.php(624): Enterprise_PageCache_Model_Processor->extractContent(false)
#9 /var/www/vhosts/vbc/httpdocs/app/code/core/Mage/Core/Model/App.php(292): Mage_Core_Model_Cache->processRequest()
#10 /var/www/vhosts/vbc/httpdocs/app/Mage.php(596): Mage_Core_Model_App->run(Array)
#11 /var/www/vhosts/vbc/httpdocs/index.php(80): Mage::run('base', 'website')
#12 {main}";s:3:"url";s:1:"/";s:11:"script_name";s:10:"/index.php";}

Funny thing is, even though I have removed all mention of Redis in the app/etc/local.xml and enterprise.xml files, this error occurs unless I completely remove the /app/code/community/Cm directory.

Any ideas?

First off, thank you for making this module. it's amazing! Makes Magento fly.

• Magento CE 1.7.0.2
• nginx
• php5-fpm
• php 5.4

Keep getting this cron

exception 'CredisException' with message ' wrong number of arguments for 'srem' command' in /var/www/magento/.modman/Cm_RedisSession/lib/Credis/Client.php:685
Stack trace:
#0 /var/www/magento/.modman/Cm_RedisSession/lib/Credis/Client.php(519): Credis_Client->read_reply('srem')
#1 /var/www/magento/.modman/Cm_Cache_Backend_Redis/Cm/Cache/Backend/Redis.php(413): Credis_Client->__call('sRem', Array)
#2 /var/www/magento/.modman/Cm_Cache_Backend_Redis/Cm/Cache/Backend/Redis.php(413): Credis_Client->sRem('zc:ti:03e_CONFI...', Array)
#3 /var/www/magento/.modman/Cm_Cache_Backend_Redis/Cm/Cache/Backend/Redis.php(453): Cm_Cache_Backend_Redis->_collectGarbage()
#4 /var/www/magento/lib/Zend/Cache/Core.php(461): Cm_Cache_Backend_Redis->clean('old', Array)
#5 /var/www/magento/lib/Varien/Cache/Core.php(100): Zend_Cache_Core->clean('old', Array)
#6 /var/www/magento/app/code/core/Mage/Core/Model/Observer.php(105): Varien_Cache_Core->clean('old')
#7 [internal function]: Mage_Core_Model_Observer->cleanCache(Object(Aoe_Scheduler_Model_Schedule))
#8 /var/www/magento/app/code/community/Aoe/Scheduler/Model/Observer.php(79): call_user_func_array(Array, Array)
#9 /var/www/magento/app/code/core/Mage/Core/Model/App.php(1338): Aoe_Scheduler_Model_Observer->dispatch(Object(Varien_Event_Observer))
#10 /var/www/magento/app/code/core/Mage/Core/Model/App.php(1317): Mage_Core_Model_App->_callObserverMethod(Object(Aoe_Scheduler_Model_Observer), 'dispatch', Object(Varien_Event_Observer))
#11 /var/www/magento/app/Mage.php(447): Mage_Core_Model_App->dispatchEvent('default', Array)
#12 /var/www/magento/cron.php(46): Mage::dispatchEvent('default')
#13 {main}

I have installed Cm_Cache_Backend_Redis on Magento Enterprise 1.12.0.2. Redis/lzf modules are listed as installed in phpinfo()

When viewing some (but not all) product pages - I am getting the following error? Redis is installed on a separate server.

Could not compress cache data.
#0 /var/www/vhosts/magento-enterprise12/.modman/Cm_Cache_Backend_Redis/Cm/Cache/Backend/Redis.php(188): Cm_Cache_Backend_Redis->_encodeData('x??}?v????�?3?P...', 1)
#1 /var/www/vhosts/magento-enterprise12/lib/Zend/Cache/Core.php(390): Cm_Cache_Backend_Redis->save('x??}?v????�?3?P...', '971_REQEST_CC0D...', Array, NULL)
#2 /var/www/vhosts/magento-enterprise12/lib/Varien/Cache/Core.php(76): Zend_Cache_Core->save('x??}?v????�?3?P...', 'REQEST_CC0DF154...', Array, NULL, 8)
#3 /var/www/vhosts/magento-enterprise12/app/code/core/Mage/Core/Model/Cache.php(380): Varien_Cache_Core->save('x??}?v????�?3?P...', 'REQEST_CC0DF154...', Array, NULL)
#4 /var/www/vhosts/magento-enterprise12/app/code/core/Enterprise/PageCache/Model/Processor.php(525): Mage_Core_Model_Cache->save('x??}?v????�?3?P...', 'REQEST_cc0df154...', Array)
#5 /var/www/vhosts/magento-enterprise12/app/code/core/Enterprise/PageCache/Model/Observer.php(97): Enterprise_PageCache_Model_Processor->processRequestResponse(Object(Mage_Core_Controller_Request_Http), Object(Mage_Core_Controller_Response_Http))
#6 /var/www/vhosts/magento-enterprise12/app/code/core/Mage/Core/Model/App.php(1338): Enterprise_PageCache_Model_Observer->cacheResponse(Object(Varien_Event_Observer))
#7 /var/www/vhosts/magento-enterprise12/app/code/core/Mage/Core/Model/App.php(1317): Mage_Core_Model_App->_callObserverMethod(Object(Enterprise_PageCache_Model_Observer), 'cacheResponse', Object(Varien_Event_Observer))
#8 /var/www/vhosts/magento-enterprise12/app/Mage.php(447): Mage_Core_Model_App->dispatchEvent('controller_fron...', Array)
#9 /var/www/vhosts/magento-enterprise12/app/code/core/Mage/Core/Controller/Varien/Front.php(186): Mage::dispatchEvent('controller_fron...', Array)
#10 /var/www/vhosts/magento-enterprise12/app/code/core/Mage/Core/Model/App.php(354): Mage_Core_Controller_Varien_Front->dispatch()
#11 /var/www/vhosts/magento-enterprise12/app/Mage.php(683): Mage_Core_Model_App->run(Array)
#12 /var/www/vhosts/magento-enterprise12/index.php(100): Mage::run('uk', 'website')
#13 {main}

We are currently using git as our repository and we use capistrano to do our deployment. I am somewhat perplexed on how we integrate modman and Cm_Cache_Backend_Redis when we deploy? Any help? Thanks

Hi Colin,

I have successfully used Cm_Cache_Backend_Redis as a single-level cache on Magento. Recently though there have been whitepapers that Redis is losing performance because it is single-threaded. Nexcess' recent whitepaper suggested that a better way forward is to use a 2-level cache using Memcache as first level, and Redis as second level, and of course applying the 2-level patch fix.

Now I know the latest version of Magento supports REDIS out of the box, but for those who are not going there yet, I wanted to ask you, does your extension allow it to be used as a second-level cache? Or is it like Cm_Cache_Backend_Files which does not support it? I could not identify this easily from the code.

If not supported, are there any plans to support it?

thanks,
Stefan

hey,

composer does not support submodules as your modman app therefore the Credis lib folder will stay empty.

Any other solution except forking and copying the Credis class into the lib folder?
Also adding the Credis module to a projects root composer.json is not an option...

Thanks!

Hello,
I think I found a big issue with the option to merge CSS/JS files on Magento and high traffic.
This issue could happen with any cache backend but I think with Redis backend the problem is bigger.

With Cm_Cache_Backend_Redis enable on a central redis server and 2 balanced webservers everything seems to work fines but if you start to get high traffic, latency goes high and I started to have big problem open pages on frontend.

Surprising only one store (I have a multistore) with a total different template had big problems, while the default one was still reachable.

I investigated lot of hours to discover that the main deal was on the CSS/JS merge files options enabled.

First of all, merged files could be bigger then single ones, this could be a problem when Magento tries to save them into the cache.

And here is the other issue, Magento seems to want to save the entire merged files into Redis cache but if the files is too much bigger magento doesn't save it and retry in one infinite loop or something like that (i'm still debugging this).

Best solution was disabled merged files and everything goes fast.

Can you reproduce this or have you any ideas? Perhaps redis can't manage big keys? Had you similar issues?
Thanks

Hi, I have just installed Cm_Cache_Backend_Redis for cache management (sessions are currently stored in Memcache).

I can see that Redis is being used (I have monitored the server with "monitor" command), but files are still being written to the var/cache/ folder.

I expected this to happen while we where using APC because it does not support tags, but reading other tutorials on the net also suggest that var/cache folder should be empty.

Is this normal?

My local.xml settings are:

<cache>
      <backend>Cm_Cache_Backend_Redis</backend>
      <backend_options>
        <server>127.0.0.1</server>
        <port>6379</port>
<!-- 
       <persistent></persistent> 
-->
        <database>0</database>
        <password></password>
        <force_standalone>0</force_standalone>
        <connect_retries>1</connect_retries>
        <read_timeout>10</read_timeout>
        <automatic_cleaning_factor>0</automatic_cleaning_factor>
        <compress_data>1</compress_data>
        <compress_tags>1</compress_tags>
        <compress_threshold>20480</compress_threshold>
        <compression_lib>gzip</compression_lib>
      </backend_options>
</cache>

Some of the files that are being cached to the file system:

mage---3f0_DB_PDO_MYSQL_DDL_log_visitor_info_1
mage---3f0_LAYOUT_16CABF9C1DBC59A000FB6D73436463A1E
mage---3f0_LAYOUT_FRONTEND_STORE1_SHOPPER_DEFAULT
mage---3f0_CONFIG_GLOBAL

I've been using the Redis caching module since last August with no difficulties. We just did an update to EE 1.13, and switched over to using the one that came packaged with Magento this last Saturday night, and this problem has happened twice now bringing the site down, once at midnight Monday morning, and then again at 11:11 PM Monday night (I noticed it was the same class essentially, but changed the configuration to point to the Mage one in lib just in case there was an update after the first time this problem happened that might have been the cause).

The site works fine until... well, I'm not sure what, and that is what I'm hoping to find out or get pointed at something to start figuring out what is wrong. Like a switch, all the page requests start returning with errors. A sample of them is here:

a:4:{i:0;s:44:"Connection to Redis failed after 2 failures.";i:1;s:1904:"#0 /var/www/html/magento/lib/Credis/Client.php(378): Credis_Client->connect()
#1 /var/www/html/magento/lib/Credis/Client.php(463): Credis_Client->connect()
#2 /var/www/html/magento/lib/Mage/Cache/Backend/Redis.php(210): Credis_Client->_call('hGet', Array)
#3 /var/www/html/magento/lib/Mage/Cache/Backend/Redis.php(210): Credis_Client->hGet('zc:k:449_FPC_DE...', 'd')
#4 /var/www/html/magento/lib/Zend/Cache/Core.php(303): Mage_Cache_Backend_Redis->load('449_FPC_DESIGN...', false)
#5 /var/www/html/magento/lib/Varien/Cache/Core.php(158): Zend_Cache_Core->load('FPC_DESIGN_EXCE...', false, false)
#6 /var/www/html/magento/app/code/core/Mage/Core/Model/Cache.php(379): Varien_Cache_Core->load('FPC_DESIGN_EXCE...')
#7 /var/www/html/magento/app/code/core/Enterprise/PageCache/Model/Processor.php(184): Mage_Core_Model_Cache->load('FPC_DESIGN_EXCE...')
#8 /var/www/html/magento/app/code/core/Enterprise/PageCache/Model/Processor.php(145): Enterprise_PageCache_Model_Processor->_getDesignPackage()
#9 /var/www/html/magento/app/code/core/Enterprise/PageCache/Model/Processor.php(107): Enterprise_PageCache_Model_Processor->_createRequestIds()
#10 /var/www/html/magento/app/code/core/Mage/Core/Model/Cache.php(703): Enterprise_PageCache_Model_Processor->__construct()
#11 /var/www/html/magento/app/code/core/Mage/Core/Model/Cache.php(685): Mage_Core_Model_Cache->_getProcessor('Enterprise_Page...')
#12 /var/www/html/magento/app/code/core/Mage/Core/Model/App.php(340): Mage_Core_Model_Cache->processRequest()
#13 /var/www/html/magento/app/Mage.php(683): Mage_Core_Model_App->run(Array)
#14 /var/www/html/magento/index.php(87): Mage::run('default', 'store')
#15 /var/www/html/magento/index_redir.php(25): require_once('/var/www/html/d...')
#16 {main}";s:3:"url";s:1:"/";s:11:"script_name";s:1:"/";}

The only action I can see in the admin log that happened just before it is a catalog pricing rules trying to be applied, and failing (it seems a bug that if the cron is running when someone tries to apply catalog price rules, it will fail, however, if I turn the off the cron from running in crontab, it always applies no problem). So, maybe something wrong if a reindex process fails (like a catalog pricing rules get reapplied and pricing gets reindexed at midnight automatically I think if I recall correctly, and this rule applying failing probably failed on the reindexing part) something messes up the full page cache that causes the module to hang? I don't know, just guessing at this point.. and the one thing I've done to basically jump start it was restart the redis services... I didn't check trying to go into the admin and flushing the cache.

Anyway, I'm not passing through a firewall between the web servers and the redis server, and am hoping that there might be a thought on how to best go about debugging this or an idea of what might be going wrong that the redis backend suddenly becomes non-accessible. Hopefully someone has some insight and can help.

Thanks for your work.

I've tried adding your package via composer as a "repository" using both of the git clone urls in my composer.json, but I always get only your "credis" library in my "vendor/colinmollenhour" directory. I even tried requiring "colinmollenhour/cache-backend-redis" (which I found in your composer.json file), but that didn't seem to exist on packagist. Any idea what might be going wrong here?

Hi, does Cm_Cache_Backend_Redis get triggered by Magento cron to cleanup cache tags (automatically)?

Or do we still need to install samm-git/cm_redis_tools.git??

Request: Would be great of Cm_Cache_Backend_Redis had default cron options to cleanup cache tags (automatically) in the module/extension

thanks for the great work

Hi Colin,
We've had a cross over occur at least once where a user on the Magento front end, ends up logged into another user's session (not on public computers, etc). Has this been reported elsewhere by people utilising your Backend_Redis setup?

Tech details:
Magento multistore EE 1.11.1 on a single CentOS server, Apache, FastCGI, latest MySQL, Redis front and back, Phoenix Varnish cache

1. I am using magento Enterprise 1.12. But not using the full page functionality of it.
2. I have installed module without modman.

Here is my config file setup for redis.

<cache>
  <backend>Cm_Cache_Backend_Redis</backend>
  <backend_options>
    <server>127.0.0.1</server> <!-- or absolute path to unix socket -->
    <port>6379</port>
    <persistent></persistent> <!-- Specify a unique string like "cache-db0" to enable persistent connections. -->
    <database>1</database>
    <password></password>
    <force_standalone>0</force_standalone>  <!-- 0 for phpredis, 1 for standalone PHP -->
    <connect_retries>1</connect_retries>    <!-- Reduces errors due to random connection failures -->
    <read_timeout>10</read_timeout>         <!-- Set read timeout duration -->
    <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>20480</compress_threshold>  <!-- Strings below this size will not be compressed -->
    <compression_lib>gzip</compression_lib> <!-- Supports gzip, lzf and snappy -->
  </backend_options>
</cache>

Now I can see the module working but there is nothing in cache. Moreover, there is nothing in var/cache/ I have gone through the few issues here and after that I created the following script.

error_reporting(E_ALL);
ini_set('display_errors', 1);

require_once '../app/Mage.php';
Mage::app('default');

$cache = Mage::app()->getCache()->getBackend();

print_r( get_class( $cache ) ) ;

$cache->save("hello world - " . time(), "test_helloworld", array("test_cache"), 60*60);

In output it shows the Cm_Cache_Backend_Redis as the way it should be.
but when I see keys * in redis-cli it shows (empty list or set)

Its clear its not storing anything on redis. Can you guys please help me out to solve this issue.

How do I know Redis Cache is working?

Is there a way in backend to see data usage and or settings for

• Redis sessions
• Redis Cache
• Redis FPC

What way it there to manage the REDIS memory usage?

In the README.md file, the modman install command is:

modman clone git://github.com/colinmollenhour/Cm_Cache_Backend_Redis.git

But if you use that, you get:

Invalid action: git://github.com/colinmollenhour/Cm_Cache_Backend_Redis.git

According to the modman docs, it looks like the modman command also needs the name of the module before the action. So something like:

modman cm clone git://github.com/colinmollenhour/Cm_Cache_Backend_Redis.git

That really threw me for a loop since I wasn't familiar with modman before attempting to install this module.

and add a modman script in to this Credis Repository.

so i think it is easier to handle this in projects

Hi Colin,

First of all, thank you for this great plugin (and modman, which I love!).

We're in a situation where we have a loadbalanced environment with two webservers (mainly for HA-purposes), each having Apache and Redis installed on them. The servers are hosting a Magento installation.

Every time something changes in the Magento database, it invalidates the corresponding part of the cache, which means it will retrieve the new information from the database. This is the expected behaviour. However, when you make these changes on one webserver, the other one still has the old cache data and will be serving it until someone manually invalidates the data on that server (either by restarting the redis server or by sheer luck).

Now, my question is, is there a way around this? I've thought of these ways:

• Some kind of TTL on cache entries that will ensure old data will never be served for more than xx minutes
• A way to make the flush or invalidation command also be sent to the other server (through configuration)
• Some kind of master/master setup for Redis

Do you see a way to make this work? We don't want Redis to become a single point of failure by using only one Redis instance, but there's also no way to specify a failover Redis instance.

Kind regards,
Jaap Haagmans

At what frequency should I run the garbage collection script?
I am using the redis for FPC and sessions. I have not implemented the GC script.

I do have an issue i hope this resolves where say customer A will see customer B shopping cart and login information. The issue is resolved if I dump the keys for session and FPC. The issue seems to be superficial where when customer A goes to check out he only sees his own cart. However the problem presents itself to my customers that the site is not safe.

Might be worthwhile to mention how to run stats.php under Related/Tuning in the readme. I deduced that I had to run it from my docroot after the Cm_Cache_Backend_Redis module has been deployed via modman.

via php ../.modman/Cm_Cache_Backend_Redis/stats.php

If I run it from .modman then it fails because required paths are wrong.

Also what values would tip us off to "oversized or wasteful cache tags"? When would we decide to use compression for instance?

Thanks!

In Magento enterprise 1.12, trying to save a SOAP/XMLRPC role results in this error: "wrong number of arguments for 'sinter' command." The problem lies in /app/code/local/Cm/Cache/Backend/Redis.php:513-516

513 public function getIdsMatchingTags($tags = array())
514 {
515 return (array) $this->_redis->sInter( $this->_preprocessTagIds($tags) );
516 }

Need to put a quick check to see if the tags array is null or empty.

Hi,

after deploying REDIS to the production servers, periodically at random times and unrelated to the load at that moment, the frontend servers end up using 100% CPU usage making the front-end unresponsive.

The site is set-up to have 3 app servers specifically for the frontend, and 1 app servers specifically for the backend admin. Sine the backend server is unaffected, I am thinking it is the FPC is cache-trashing.

Clearing or restarting REDIS has no effect. Restarting the zend services on the frontend servers seems to fix it. The unfortunate thing is this is not happening on the test environment (which is configured exactly the same).

Any help please? I cannot figure out what the issue could be. For the next steps I was going to switch off phpredis, and enable automatic cleaning factor, to see if it keeps happening, but of these will slow down the system.

Magento version is 1.9.0.0 EE
Redis version is 2.6.12
phpredis is installed on the app servers, latest from repository (2.2.3?)
lzf compression is installed
We set a cron job on the redis server that clears the cache completely using "redis-cli flushall" at 6am

Configuration on all 4 servers is the same
<cache>
<backend>Cm_Cache_Backend_Redis</backend>
<backend_options>
<server>xxx.xxx.xxx.xxx</server> <!-- or absolute path to unix socket -->
<port>6379</port>
<persistent>cache-db0</persistent> <!-- Specify a unique string like "cache-db0" to enable persistent connections. -->
<database>0</database>
<password></password>
<force_standalone>0</force_standalone> <!-- 0 for phpredis, 1 for standalone PHP -->
<connect_retries>1</connect_retries> <!-- Reduces errors due to random connection failures -->
<read_timeout>10</read_timeout> <!-- Set read timeout duration -->
<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>20480</compress_threshold> <!-- Strings below this size will not be compressed -->
<compression_lib>lzf</compression_lib> <!-- Supports gzip, lzf and snappy -->
</backend_options>
</cache>

Output of "info all" during a non-peak moment (now):
redis 127.0.0.1:6379> info all

Server

redis_version:2.6.12
redis_git_sha1:00000000
redis_git_dirty:0
redis_mode:standalone
os:Linux 2.6.18-348.4.1.el5 x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.1.2
process_id:3566
run_id:f7ac169ac2700d731b359ef3cf86ac38e6602780
tcp_port:6379
uptime_in_seconds:147149
uptime_in_days:1
hz:10
lru_clock:707773

Clients

connected_clients:25
client_longest_output_list:2
client_biggest_input_buf:0
blocked_clients:0

Memory

used_memory:806210760
used_memory_human:768.86M
used_memory_rss:865255424
used_memory_peak:847086696
used_memory_peak_human:807.84M
used_memory_lua:31744
mem_fragmentation_ratio:1.07
mem_allocator:jemalloc-3.2.0

Persistence

loading:0
rdb_changes_since_last_save:10793859
rdb_bgsave_in_progress:0
rdb_last_save_time:1370079388
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:-1
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok

Stats

total_connections_received:278236
total_commands_processed:100407515
instantaneous_ops_per_sec:463
rejected_connections:0
expired_keys:176335
evicted_keys:0
keyspace_hits:63930946
keyspace_misses:2027440
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:0

Replication

role:master
connected_slaves:0

CPU

used_cpu_sys:1706.26
used_cpu_user:931.63
used_cpu_sys_children:0.00
used_cpu_user_children:0.00

Commandstats

cmdstat_del:calls=407549,usec=3057946,usec_per_call=7.50
cmdstat_sadd:calls=32728843,usec=63358464,usec_per_call=1.94
cmdstat_srem:calls=389842,usec=842764,usec_per_call=2.16
cmdstat_sunion:calls=360857,usec=2499681,usec_per_call=6.93
cmdstat_hget:calls=65101268,usec=325685595,usec_per_call=5.00
cmdstat_hmset:calls=496261,usec=4722766,usec_per_call=9.52
cmdstat_select:calls=426630,usec=1788001,usec_per_call=4.19
cmdstat_expire:calls=496261,usec=1375386,usec_per_call=2.77
cmdstat_flushall:calls=2,usec=4346262,usec_per_call=2173131.00
cmdstat_info:calls=2,usec=566,usec_per_call=283.00

Keyspace

db0:keys=19080,expires=14261

thanks,
Stefan

Hi, i installed the module on a magento entreprise 1.12.0.2 to manage cache, but when implement it, Mage write the cache entries in redis db, but seems it don't load cache .

Do you have an idea for that strange issue ?

regards
Jerome longet

for eg here is the profiler trace with standard cache config.

first load, call load-db
Code Profiler Time Cnt Emalloc RealMem
mage 4.6410 1 0 0
mage::app::init::system_config 0.0015 1 141,048 0
CORE::create_object_of::Mage_Core_Model_Cache 0.0028 2 675,040 786,432
CORE::create_object_of::Mage_Core_Model_Resource_Cache 0.0005 1 110,248 262,144
DISPATCH EVENT:resource_get_tablename 0.0003 34 4,896 0
config/load-modules 0.2655 1 5,032 786,432
config/load-modules-declaration 0.0514 1 359,088 786,432
mage::app::init::apply_db_schema_updates 0.0630 1 5,665,456 4,980,736
config/load-db 1.1358 1 110,200 524,288
mage::app::init::stores 0.0264 1 2,348,440 2,359,29
.....

the second load, call load_cache.
Code Profiler Time Cnt Emalloc RealMem
mage 0.2067 1 0 0
mage::app::init::system_config 0.0015 1 141,048 0
CORE::create_object_of::Mage_Core_Model_Cache 0.0027 2 675,040 786,432
mage::app::init::config::load_cache 0.0077 1 2,256 0
mage::app::init::stores 0.0263 1 5,629,104 5,767,168
CORE::create_object_of::Mage_Core_Model_Resource_Website 0.0005 1 110,240

with redis

first load
Code Profiler Time Cnt Emalloc RealMem
mage 3.1875 1 0 0
mage::app::init::system_config 0.0016 1 140,984 0
CORE::create_object_of::Mage_Core_Model_Cache 0.0041 2 1,058,760 1,048,576
CORE::create_object_of::Mage_Core_Model_Resource_Cache 0.0005 1 110,224 0
DISPATCH EVENT:resource_get_tablename 0.0059 72 14,400 0
config/load-modules 0.2648 1 5,032 524,288
config/load-modules-declaration 0.0514 1 359,088 524,288
mage::app::init::apply_db_schema_updates 0.0697 1 5,635,648 5,242,880
config/load-db 1.1121 1 110,248 524,288

second, third load....
Code Profiler Time Cnt Emalloc RealMem
mage 3.1905 1 0 0
mage::app::init::system_config 0.0016 1 140,984 0
CORE::create_object_of::Mage_Core_Model_Cache 0.0041 2 1,058,760 1,048,576
CORE::create_object_of::Mage_Core_Model_Resource_Cache 0.0005 1 110,224 0
DISPATCH EVENT:resource_get_tablename 0.0059 72 14,400 0
config/load-modules 0.2655 1 5,032 524,288
config/load-modules-declaration 0.0516 1 359,088 524,288
mage::app::init::apply_db_schema_updates 0.0693 1 5,635,648 5,242,880
config/load-db 1.1118 1 110,248 524,288
mage::app::init::stores 0.0346 1 2,344,296 1,835,00

Cache entries
zc:ti:e62_BACKEND_MAINMENU zc:ti:e62_COLLECTION_DATA zc:ti:e62_DEFAULT zc:ti:e62_LAYOUT_GENERAL_CACHE_TAG zc:tags zc:ti:e62_STORE zc:ti:e62_TRANSLATE zc:ti:e62_DB_PDO_MYSQL_DDL zc:ti:e62_WEBSITE zc:ti:e62_STORE_ADMIN zc:ti:e62_CONFIG zc:ti:e62_STORE_GROUP zc:ti:e62_MAGE zc:ti:e62_THEME_ADMINHTML_DEFAULT_WP zc:ti:e62_ADMINHTML_SYSTEM_CONFIG_EDIT zc:ti:e62_ADMINHTML....

I found that garbage collector crashing when working on very large tags. Tag MAGE has about 160k records and was crashing on memory limit (about 1Gb) when doing sRem in pipeline mode. I did a small patch to prevent such crash:

samm-git/cm_redis_tools@7487000

To test the issue i did a small wrapper @ https://github.com/samm-git/cm_redis_tools/blob/master/rediscli.php

Thank you very much for this! The benchmarks on paper are incredible, and so far it seems pretty fast in the environment we're running it in.

So.. phpredis has support to use multiple redis instances in an array (https://github.com/nicolasff/phpredis/blob/master/arrays.markdown#readme)

To me, this seems akin to having multiple Memcached instances. Is there support for this in the Redis cache backend? The docs (and config example) seem as though only one instance is permitted. Would it be possible to clarify that?

Thank you again!

Hi Colin,

We are facing a unique situation here: if you have a look at the data given below, the key is added to the set and then removed from the set in the next call itself, we are at our wit's as to why they would be happening.

+1342204431.608065 "hget" "zc:k:403_PAGE_POPULAR_SEARCHES_BRANDS_1_ID_105__KEY" "d"
+1342204431.613158 "hget" "zc:k:403_PAGE_FOOTER_1__DEFAULT_XBANDRA_KEY" "d"
+1342204431.615404 "hget" "zc:k:403_PAGE_FOOTER_1__DEFAULT_XBANDRA_KEY" "t"
+1342204431.616109 "multi"
+1342204431.616141 "hmset" "zc:k:403_PAGE_FOOTER_1__DEFAULT_XBANDRA_KEY" "d" "

If Cm_Cache_Backend_Redis is not installed, attempts to use return the error

PHP Fatal error: Class 'Credis_Client' not found in /.modman/Cm_RedisSession/code/Model/Session.php on line 93

We have moved to a 2 server setup:

1 for the live website
1 for the admin system only

In both configurations I have entered the IP/port number of the redis server. Using the admin interface I am able to select the cache to clear (and it reports success). However, I am fairly certain that using redis-cli/monitor on the server that the request is sent to clear the cache but nothing actually get's cleared.

Any ideas?

Please ignore. I meant to file this in the Cm_Cache_Backend_File project.

Is there a configuration so that Magento will revert to database or file caching if the Redis server is down? Currently the site goes down if the Redis server is down.

Hi Colin,

I'm unable to get the Magento EE respecting the port setting for FPC. In fact, the constructor for CM/Cache/Backend/Redis is only called once.

The <full_page_cache> section is identical to the one you use in the README, with exception of server and port. I've added a line to the top of the constructor:

         Mage::log(
            'Constructing Redis Cache Backend using ' . $options['server']
                . ':' .  $options['port'],
            null,
            'redis.log'
        );

And this only gets called for the block on the standard 6379 port, while the <full_page_cache> backend_options use port 6381.

On the main redis server I do see the following:
`redis 127.0.0.1:6379> keys FPC

1. "zc:ti:823_FPC"`

So my suspicions are that the cache backend is being used as a singleton and one cannot split the containers. If so, it would deserve a warning in the README.md. If not, what would be going wrong here and how would I go about debugging it.

Not an issue, but unclarity

Now that this extension exists, how does it overlap with this one: https://github.com/colinmollenhour/Cm_RedisSession

If I want to store both var/cache and var/session via Redis: should I then install both separately?

And maybe as a hint: how much memory should we reserve for either on a single install and between 10-100 products?

And is there a good Magento setup guide somewhere that you know of for installing on a Magento VPS server?

Maybe you could add some clarifications in the text

ps. Thanks for your wonderful extension

Hello,
I have this problem on my environment, Magento 1.5.1.0 with latest CM_Cache_Backend_Redis and phpredis.
It seems that when Amazon AWS autoscaling triggers a new instance, this new one has problem to connect to the shared redis server.
The first 5/6 tries it fails, then it can reach the redis server and eveything works fine.

But everytime a new instance is triggered I get var/report files with error like this:

a:4:{i:0;s:44:"Connection to Redis failed after 2 failures.";i:1;s:1818:"#0 /var/virtual/store.simplicissimus.it/lib/Credis/Client.php(326): Credis_Client->connect()
#1 /var/virtual/store.simplicissimus.it/lib/Credis/Client.php(326): Credis_Client->connect()
#2 /var/virtual/store.simplicissimus.it/lib/Credis/Client.php(326): Credis_Client->connect()
#3 /var/virtual/store.simplicissimus.it/lib/Credis/Client.php(411): Credis_Client->connect()
#4 /var/virtual/store.simplicissimus.it/lib/Credis/Client.php(404): Credis_Client->__call('select', Array)
#5 /var/virtual/store.simplicissimus.it/app/code/community/Cm/Cache/Backend/Redis.php(112): Credis_Client->select(1)
#6 /var/virtual/store.simplicissimus.it/lib/Zend/Cache.php(153): Cm_Cache_Backend_Redis->__construct(Array)
#7 /var/virtual/store.simplicissimus.it/lib/Zend/Cache.php(94): Zend_Cache::_makeBackend('Cm_Cache_Backen...', Array, true, true)
#8 /var/virtual/store.simplicissimus.it/app/code/core/Mage/Core/Model/Cache.php(117): Zend_Cache::factory('Varien_Cache_Co...', 'Cm_Cache_Backen...', Array, Array, true, true, true)
#9 /var/virtual/store.simplicissimus.it/app/code/core/Mage/Core/Model/Config.php(1254): Mage_Core_Model_Cache->__construct(Array)
#10 /var/virtual/store.simplicissimus.it/app/Mage.php(432): Mage_Core_Model_Config->getModelInstance('core/cache', Array)
#11 /var/virtual/store.simplicissimus.it/app/code/core/Mage/Core/Model/App.php(384): Mage::getModel('core/cache', Array)
#12 /var/virtual/store.simplicissimus.it/app/code/core/Mage/Core/Model/App.php(282): Mage_Core_Model_App->_initCache()
#13 /var/virtual/store.simplicissimus.it/app/code/core/Mage/Core/Model/App.php(324): Mage_Core_Model_App->baseInit(Array)
#14 /var/virtual/store.simplicissimus.it/app/Mage.php(627): Mage_Core_Model_App->run(Array)
#15 /var/virtual/store.simplicissimus.it/index.php(80): Mage::run('default', 'store')
#16 {main}";s:3:"url";s:109:"/jsonsearch/result/category/status/1/category_id/2589/?foo=1&format=json&price_start=00.00&price_end=0.99&p=5";s:11:"script_name";s:10:"/index.php

I tried to raise the connection retries but it doesn't work.
Any ideas?

Please see this issue regarding n98-magerun’s failure to wait for completion of blocking Redis commands.

Do you agree with my analysis that Credis Client’s behavior is correct and the n98-magerun behavior is inadequate? How would you check for the status of the backend before trying to clear FPC?

Hi,

When magento compiler option is used the inclusion of Credis_Client fails

Class 'Credis_Client' not found in /includes/staging/src/Cm_Cache_Backend_Redis.php on line 71

To solve this I moved the /lib/Credis/Client file into the CM module folder and placed a require_once directive on the Redis.php code to implicitly include the client file.

Hi Colin,

On this site, I'm connecting to redis using a named socket, rather than a TCP port. This raises the following in the magento var/log/system.log

Notice: Undefined index: port in .../.modman/Cm_Cache_Backend_Redis/Cm/Cache/Backend/Redis.php on line 96

Nothing important, just fills up the log and makes real errors that bit more difficult to find.

Code is up to date, Magento CE 1.7.0.2.

Cheers,

Steve

Redis server is 2.8.8. CM Cache is master (today). Magento is EE 1.13.1.0.

a:4:{i:0;s:44:"Connection to Redis failed after 2 failures.";i:1;s:2025:"#0 /var/www/vhosts/magento-capistrano/releases/20140408095059/.modman/Cm_RedisSession/lib/Credis/Client.php(362): Credis_Client->connect()
#1 /var/www/vhosts/magento-capistrano/releases/20140408095059/.modman/Cm_RedisSession/lib/Credis/Client.php(447): Credis_Client->connect()
#2 /var/www/vhosts/magento-capistrano/releases/20140408095059/.modman/Cm_RedisSession/lib/Credis/Client.php(440): Credis_Client->__call('select', Array)
#3 /var/www/vhosts/magento-capistrano/releases/20140408095059/.modman/Cm_Cache_Backend_Redis/Cm/Cache/Backend/Redis.php(125): Credis_Client->select(0)
#4 /var/www/vhosts/magento-capistrano/releases/20140408095059/lib/Zend/Cache.php(153): Cm_Cache_Backend_Redis->__construct(Array)
#5 /var/www/vhosts/magento-capistrano/releases/20140408095059/lib/Zend/Cache.php(94): Zend_Cache::_makeBackend('Cm_Cache_Backen...', Array, true, true)
#6 /var/www/vhosts/magento-capistrano/releases/20140408095059/app/code/core/Mage/Core/Model/Cache.php(137): Zend_Cache::factory('Varien_Cache_Co...', 'Cm_Cache_Backen...', Array, Array, true, true, true)
#7 /var/www/vhosts/magento-capistrano/releases/20140408095059/app/code/core/Mage/Core/Model/Config.php(1348): Mage_Core_Model_Cache->__construct(Array)
#8 /var/www/vhosts/magento-capistrano/releases/20140408095059/app/Mage.php(463): Mage_Core_Model_Config->getModelInstance('core/cache', Array)
#9 /var/www/vhosts/magento-capistrano/releases/20140408095059/app/code/core/Mage/Core/Model/App.php(401): Mage::getModel('core/cache', Array)
#10 /var/www/vhosts/magento-capistrano/releases/20140408095059/app/code/core/Mage/Core/Model/App.php(295): Mage_Core_Model_App->_initCache(Array)
#11 /var/www/vhosts/magento-capistrano/releases/20140408095059/app/code/core/Mage/Core/Model/App.php(337): Mage_Core_Model_App->baseInit(Array)
#12 /var/www/vhosts/magento-capistrano/releases/20140408095059/app/Mage.php(684): Mage_Core_Model_App->run(Array)
#13 /var/www/vhosts/magento-capistrano/releases/20140408095059/index.php(112): Mage::run('uk', 'website')

local.xml snippet:

 <cache>
        <backend>Cm_Cache_Backend_Redis</backend>
           <backend_options>
                <server><![CDATA[/tmp/redis_6379.sock]]></server> <!-- or absolute path to unix socket -->
                <port>6379</port>
                <persistent>cache-db0</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>1</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>20480</compress_threshold>  <!-- Strings below this size will not be compressed -->
                <compression_lib>lzf</compression_lib> <!-- Supports gzip, lzf, lz4 (as l4z) and snappy -->
                <use_lua>0</use_lua> <!-- Set to 1 if Lua scripts should be used for some operations -->
           </backend_options>
        </cache>
        <full_page_cache>
           <backend>Cm_Cache_Backend_Redis</backend>
                <backend_options>
                <server><![CDATA[/tmp/redis_6379.sock]]></server> <!-- or absolute path to unix socket -->
                <port>6379</port>
                <persistent>fpc-db1</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>1</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>1</connect_retries>    <!-- Reduces errors due to random connection failures -->
                <lifetimelimit>57600</lifetimelimit>    <!-- 16 hours of lifetime for cache record -->
                <compress_data>0</compress_data>        <!-- DISABLE compression for EE FPC since it already uses compression -->
           </backend_options>
        </full_page_cache>

ls -la /tmp/redis_6379.sock

srwxr-xr-x 1 root root 0 Apr  9 11:07 /tmp/redis_6379.sock

ps aux | grep redis

root     13030  0.5  0.0  42120  2824 ?        Ssl  11:07   0:04 /opt/redis/bin/redis-server *:6379 

redis-cli -s /tmp/redis_6379.sock

redis /tmp/redis_6379.sock> 

./redis-benchmark -q -n 10000 -s /tmp/redis_6379.sock

PING_INLINE: 60975.61 requests per second
PING_BULK: 62893.08 requests per second
SET: 63291.14 requests per second
GET: 62893.08 requests per second
INCR: 63694.27 requests per second
LPUSH: 63694.27 requests per second
LPOP: 63694.27 requests per second
SADD: 63291.14 requests per second
SPOP: 63694.27 requests per second
LPUSH (needed to benchmark LRANGE): 63694.27 requests per second
LRANGE_100 (first 100 elements): 37313.43 requests per second
LRANGE_300 (first 300 elements): 16611.29 requests per second
LRANGE_500 (first 450 elements): 12062.73 requests per second
LRANGE_600 (first 600 elements): 9587.73 requests per second
MSET (10 keys): 55555.55 requests per second

Hello,
I've installed Redis, phpredis and Cm_Cache_Backend_Redis extension with no issues, however, I see that the cache is still being written to /var/cache instead of Redis.

redis-cli monitor command produces no activity, there are also no keys being written.

What could be causing this issue? Thank you in advance!

Here is the redis-cli info:

# Server
redis_version:2.6.16
redis_git_sha1:00000000
redis_git_dirty:0
redis_mode:standalone
os:Linux 2.6.32-358.2.1.el6.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.7
process_id:26253
run_id:379b28aee25cebd4f5ce807040f6d44686c66840
tcp_port:6379
uptime_in_seconds:2250
uptime_in_days:0
hz:10
lru_clock:2064835

# Clients
connected_clients:1
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0

# Memory
used_memory:849720
used_memory_human:829.80K
used_memory_rss:2043904
used_memory_peak:848952
used_memory_peak_human:829.05K
used_memory_lua:31744
mem_fragmentation_ratio:2.41
mem_allocator:jemalloc-3.2.0

# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1383796714
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok

# Stats
total_connections_received:7
total_commands_processed:12
instantaneous_ops_per_sec:0
rejected_connections:0
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:187

# Replication
role:master
connected_slaves:0

# CPU
used_cpu_sys:0.21
used_cpu_user:0.18
used_cpu_sys_children:0.00
used_cpu_user_children:0.00

# Keyspace

When i try to install Cm_Cache_Backend_Redis but it says 'line 884: git: command not found
Error trying to clone new module 'Cm_Cache_Backend_Redis', operation cancelled.' Do you know that how can i fix this problem?

Thanks.

Hi,

We were using Zend_Cache_Backend_Redis earlier and now testing out the Cm_Cache_Backend_Redis. I notice that there are many calls with SELECT 0, as the cache is being queried, it invariably stops for second and then I see this call for the database 0. I am trying to find out why this happens but no luck so far, the redis connection timeout is set to 17 seconds.

+1340932859.107901 "HGET" "zc:k:2fb_DB_PDO_MYSQL_DDL_log_url_info_1" "d"
+1340932859.111735 "HGET" "zc:k:2fb_DB_PDO_MYSQL_DDL_log_url_1" "d"
+1340932860.425654 "SELECT" "0"
+1340932860.427008 "SELECT" "0"
+1340932860.427105 "SELECT" "0"
+1340932860.427208 "HGET" "zc:k:2fb_CORE_CACHE_OPTIONS" "d"
+1340932860.428784 "HGET" "zc:k:2fb_CORE_CACHE_OPTIONS" "d"
+1340932860.429159 "HGET" "zc:k:2fb_CONFIG_GLOBAL_LOCK" "d"
+1340932860.429272 "HGET" "zc:k:2fb_CONFIG_GLOBAL_LOCK" "d"
+1340932860.429390 "SELECT" "0"
+1340932860.429405 "HGET" "zc:k:2fb_CORE_CACHE_OPTIONS" "d"
+1340932860.429502 "HGET" "zc:k:2fb_CONFIG_GLOBAL" "d"
+1340932860.429642 "HGET" "zc:k:2fb_CONFIG_GLOBAL" "d"
+1340932860.429861 "SELECT" "0"
+1340932860.429987 "HGET" "zc:k:2fb_CONFIG_GLOBAL_LOCK" "d"
+1340932860.430351 "HGET" "zc:k:2fb_CONFIG_GLOBAL" "d"
+1340932860.431517 "HGET" "zc:k:2fb_CORE_CACHE_OPTIONS" "d"
+1340932860.431817 "HGET" "zc:k:2fb_CONFIG_GLOBAL_LOCK" "d"
+1340932860.432125 "HGET" "zc:k:2fb_CONFIG_GLOBAL" "d"
+1340932860.434004 "HGET" "zc:k:2fb_CORE_CACHE_OPTIONS" "d"
+1340932860.454322 "HGET" "zc:k:2fb_CONFIG_GLOBAL_LOCK" "d"
+1340932860.454621 "HGET" "zc:k:2fb_CONFIG_GLOBAL" "d"

Cheers,
Sanjay

I have setup a new redis standalone server running CentOS 6.4 with a redis instance for cache and another for session.

I have 6 servers running magento with a shared database all running a high volume store. They are behind a load balancer. Each one is pointing at the single redis instance.

In the persistent connections option in local.xml I am wondering if I should be using the same persistence key on each server or should each one have it's own key?

I am only using cache back end at the moment. With a seperate key for each I am seeing high load in newrelic reporting on redis?

Secondly, would it be better to have a local redis install instead for each server?

The aim is to handle 10,000 concurrent shoppers

Thanks

I don't see in the documentation or in the config example if you support redis auth? For security we have auth enabled since we run multiple redis instances for multiple customers. If you don't currently support auth is this something you could add as phpredis already supports it. Thanks