Using Redis cache backend and session storage in Magento

Redis Logo

Combined with the power of Zend Framework, Magento currently supports many cache backends with file system, APC and Memcached being the most widely used. Every supported cache backend brings it’s own set of upsides and downsides, but since there’s a lot to choose from, one could easily assume that as far as cache backends are concerned, Magento is very well covered. To some degree this might be true, but when you seriously up the number of requests, none of the cache backends scale well. Besides poor scaling, some of the cache backend implementations also suffer from serious limitations like not having support for grouping of related cache entries, a.k.a. tagging. With this in mind, and in order to provide support for stable and scalable cache backend, latest versions of Magento are turning to Redis key-value store. In this article I’ll do my best to describe process of implementing Redis as cache and session backend with recent versions of Magento Community and Enterprise Edition.

Installing Redis

As far as Magento is concerned, Redis consists of two key parts, first being the server it self and second PhpRedis extension that allows PHP to communicate with Redis. I’ll show you how to install both parts on top of both server and workstation Linux configurations. For the sake of keeping this article concise, I’ll make the assumption that the server configuration is being powered by CentOS in it’s version 6, and that the developer configuration is using latest Ubuntu version at the time of writing, Ubuntu 13.10. Although following procedure doesn’t cover every Linux distribution out there, it does generally cover two main camps, RedHat and Debian based Linux distributions.

Server configuration – CentOS 6.0 or later

Easiest way to install Redis on RedHat based Linux distributions like CentOS is to use EPEL (Extra Packages for Enterprise Linux) repository. This comes down to installing one package and importing EPEL repository GPG key. I must point out that there’s high probability that your CentOS server already has this repository added (you can use yum repolist to test). First step, download package that adds the repository to yum package manager. If you’re using i386 kernel and environment (command uname -r to test) use following line:

wget http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

On the other hand if you are using x86_64 kernel, you should execute following line from your shell:

wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

Next step is to install repository package and import GPG key used by yum to authenticate packages (root access required):

rpm -Uvh epel-release-6*.rpm
rpm --import http://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-6

What’s left to do is install Redis server and PhpRedis extension trough yum, enable the Redis server to be started at boot, start Redis service and restart Apache service:

su
yum install redis php-pecl-redis
chkconfig redis on
service redis start
service httpd restart

Workstation configuration – Ubuntu 13.10 or later

Good news, Debian has Redis server in it’s repository since Wheezy (in previous Squeeze version you had to use backports repository), so we do not have to add new repositories to our Ubuntu system. Bad news, there is no PhpRedis package in any of the repositories, so we must compile the thing with a little help from our good old friend PECL. So let’s proceed with installing the Redis server (administrative user access required):

sudo -i
apt-get install redis-server php5-dev php5-cli php-pear

Next, we install PhpRedis extension trough PECL, inform PHP about it’s existence, enable the PHP extension and restart Apache service:

pecl install redis
echo "extension=redis.so" > /etc/php5/mods-available/redis.ini
php5enmod redis
service apache2 restart

Verifying Redis installation

At this point we should be ready to test basic operations of Redis as well as it’s PHP extension.

Verifying Redis server

To test Redis server, we simply ping it using:

redis-cli ping

If you have received your PONG, you can proceed.

Verifying PhpRedis extension

To see if Redis extension is being loaded by PHP we can grep the output of php -m shell command:

php -m | grep redis

We expect string redis as a result.

Redis shell tools

Redis comes with a few tools, most useful one being it’s client software accessible trough following shell command:

redis-cli

After starting Redis client, you are presented with Redis console where you can enter supported commands. Some of the commands you’ll be using most of the time are definitely:

  • FLUSHALL – clear all databases
  • SELECT # – select database under index #
  • FLUSHDB – empty currently selected database
  • KEYS * – list all keys from currently selected

Good thing to point out regarding Redis is that databases are created on demand and that they can only be indexed by integers. Default number of databases is 16, but this and many other parameters can be configured trough Redis main configuration file located at /etc/redis/redis.conf for CentOS and /etc/redis/redis.conf for Debian based distributions.

Redis support across different Magento versions

Since Redis joined Magento cache and session backends not so long ago after being community project for a while, level of support Magento provides out the box varies with Magento version.

Here are the links to community projects that brought Redis support to Magento:

    In case your Magento version is missing support for Redis cache or session backend (or both), you can freely download and use community extensions. Here’s short overview of Redis cache and session backends out the box support for recent Magento CE and EE versions.

    Magento CE >= 1.7.0.0 and < 1.8.0.0

    • Session storage – not included
    • Cache backend – not included, after installation available as Cm_Cache_Backend_Redis

    Magento CE >= 1.8.0.0

  • Session storage – included
  • Cache backend – included, available as Mage_Cache_Backend_Redis

Magento EE >= 1.13.0.0 and < 1.13.1.0

  • Session storage – not included
  • Cache backend – included, available as Mage_Cache_Backend_Redis

Magento EE >= 1.13.1.0

  • Session storage – included
  • Cache backend – included, available as Mage_Cache_Backend_Redis

Using Redis cache backend

When placed inside app/etc/local.xml, following code configures Redis cache backend to use database with index 0 to hold cache:

<config>
    <global>
 
        <!-- other configuration nodes -->
 
        <cache>
          <backend>CACHE_BACKEND_CLASS_NAME</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>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>gzip</compression_lib> <!-- Supports gzip, lzf and snappy -->
          </backend_options>
        </cache>
 
        <!-- other configuration nodes -->
 
    </global>
</config>

Replace CACHE_BACKEND_CLASS_NAME with relevant cache backend class name as specified under “Redis support across different Magento versions” heading.

After enabling Redis as cache backend, var/cache directory of your Magento installation can be emptied and should stay empty. If you are using Magento Enterprise edition and cache backend that supports tagging for full page cache, similar thing goes for core_cache/core_cache_tag tables from your Magento database because in this case these tables can be truncated and should stay empty. To check is Redis backend being used for storing cache you can run redis-cli tool and query database 1 using following Redis commands:

SELECT 0
KEYS *

Using Redis as FPC backend (Magento Enterprise Edition only)

When placed inside app/etc/local.xml, following code configures Redis cache backend to use database with index 1 to hold full page cache:

<config>
    <global>
 
        <!-- other configuration nodes -->
 
        <full_page_cache>
            <backend>CACHE_BACKEND_CLASS_NAME</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>      <!-- Separate database 1 to keep FPC separately -->
              <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 -->
              <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>
 
        <!-- other configuration nodes -->
 
    </global>
</config>

Replace CACHE_BACKEND_CLASS_NAME with relevant cache backend class name as specified under “Redis support across different Magento versions” heading.

After enabling Redis as full page cache backend, var/full_page_cache directory of your Magento Enterprise Edition installation can be emptied and should stay empty. If you are using cache backend that supports tagging for cache, similar thing goes for core_cache/core_cache_tag tables from your Magento database because in this case these tables can be truncated and should stay empty. To check is Redis backend being used for storing full page cache you can run redis-cli tool and query database 1 using following Redis commands:

SELECT 1
KEYS *

Cache tags cleanup cron

Redis solves most problems that affect other cache backends, but cleaning up old cache tags manually is still required. Luckily, Magento provides garbage cleanup PHP script designed to be run by cron daily to remedy this issue.

Step one, clone the GitHub repository that hosts garbage cleanup PHP script on path accessible to user that will be running this script from it’s crontab (/some/path/ in this example):

su
cd /some/path/
git clone git@github.com:samm-git/cm_redis_tools.git
cd cm_redis_tools
git submodule update --init --recursive

Next step, edit crontab as this user:

crontab -e

and add this script to be started every night:

30 2 * * * /usr/bin/php /some/path/cm_redis_tools/rediscli.php -s 127.0.0.1 -p 6379 -d 0,1

where -s parameter is Redis server host, -p port and -d coma separated list of databases to clean. If you remember, we’ve used 0 for cache and 1 for full page cache so adjust as necessary. Also, don’t forget to adjust /some/path/ into whatever path you’ve chosen before cloning the repository.

Using Redis session storage

As first step you should make sure that CM_RedisSession module is active by editing app/etc/modules/CM_RedisSession.xml, because this isn’t the case in Magento versions that support Redis as session storage out the box.

Another thing worth mentioning is that following code snippet sets session storage to db. Reason for this is that Redis session works by rewriting Mage_Core_Model_Mysql4_Session.

With this in mind, here’s code that configures Redis session model to use database with index 2, when placed inside app/etc/local.xml.

<config>
    <global>
 
        <!-- other configuration nodes -->
        <session_save>db</session_save>
        <redis_session>                       <!-- All options seen here are the defaults -->
            <host>127.0.0.1</host>            <!-- Specify an absolute path if using a unix socket -->
            <port>6379</port>
            <password></password>             <!-- Specify if your Redis server requires authentication -->
            <timeout>2.5</timeout>            <!-- This is the Redis connection timeout, not the locking timeout -->
            <persistent></persistent>         <!-- Specify unique string to enable persistent connections. -->
            <db>2</db>                        <!-- Redis database number; protection from accidental loss is improved by using a unique DB number for sessions -->
            <compression_threshold>2048</compression_threshold>  <!-- Set to 0 to disable compression (recommended when suhosin.session.encrypt=on); known bug with strings over 64k: https://github.com/colinmollenhour/Cm_Cache_Backend_Redis/issues/18 -->
            <compression_lib>gzip</compression_lib>              <!-- gzip, lzf or snappy -->
            <log_level>4</log_level>               <!-- 0 (emergency: system is unusable), 4 (warning; additional information, recommended), 5 (notice: normal but significant condition), 6 (info: informational messages), 7 (debug: the most information for development/testing) -->
            <max_concurrency>6</max_concurrency>                 <!-- maximum number of processes that can wait for a lock on one session; for large production clusters, set this to at least 10% of the number of PHP processes -->
            <break_after_frontend>5</break_after_frontend>       <!-- seconds to wait for a session lock in the frontend; not as critical as admin -->
            <break_after_adminhtml>30</break_after_adminhtml>
            <bot_lifetime>7200</bot_lifetime>                    <!-- Bots get shorter session lifetimes. 0 to disable -->
        </redis_session>
 
        <!-- other configuration nodes -->
 
    </global>
</config>

Migrate sessions to Redis

If you are implementing Redis on a live store, you should import current sessions before you proceed. This should be done with your store in maintenance mode. Cm_RedisSession project provides two scripts for this purpose. Which one you use depends on whether you’ve been using files or db session backend before implementing Redis.

Here’s procedure if you were previously using files for storing session data:

cd /path/to/magento/root
touch maintenance.flag
sleep 10
wget https://raw2.github.com/colinmollenhour/Cm_RedisSession/master/migrateSessions.php
php migrateSessions.php -y
rm maintenance.flag

And here’s procedure if you were previously using database for storing session data:

cd /path/to/magento/root
touch maintenance.flag
sleep 10
wget https://raw2.github.com/colinmollenhour/Cm_RedisSession/master/migrateSessions_mysql_redis.php
php migrateSessions_mysql_redis.php -y
rm maintenance.flag

After enabling Redis as session backend, var/sessions directory of your Magento installation can be emptied and should stay empty. Similar thing goes for core_session table from your Magento database because in this case this table can be truncated and should stay empty. To check is Redis model being used for storing sessions you can run redis-cli tool and query database 2 using following Redis commands:

SELECT 2
KEYS *

That’s all there is to implementing Redis with Magento. I hope you found this article useful and until next time, I wish you happy coding!


39 comments

  1. Informative and detailed article. It answered all the questions I had about implementing Redis and more. Thanks for the help.

  2. I used the git bash on my windows prompt.
    I was able to get the cm redis tools by ‘git clone git@github.com:samm-git/cm_redis_tools.git’ git command.
    But fail at ‘git submodule update –init –recursive’ command. The error message is as following:

    Cloning into ‘lib/Credis’…
    fatal: unable to connect to github.com:
    github.com[0: 192.30.253.113]: errno=Invalid argument

    fatal: clone of ‘git://github.com/colinmollenhour/credis.git’ into submodule path ‘lib/Credis’ failed

    How can I fix it?

  3. Marko,
    Thanksyou very much for the writeup very useful for Magento1. Can you please update post this Magento 2 ?

  4. Thanks for the fabulous article Marko – we’re working on a Magento store and we found Redis caching the way you described to be very easy to implement.

    After the Redis change we found reduced auto-scaling (we’re using AWS) and better performance overall. Superb!

  5. Hi Marko,

    Thank you for the article.

    Can Marko or anyone here please share your thoughts on how can we do production deployment without taking the system down. Since if we have our cache in Redis, we need to clear that cache once we deploy new code or upgrade script. Its kind of deleting and recreating the cache bucket altogether which require to stop requests coming to the production server for a min or so. Please advice how can we avoid that.

    Regards,
    -Senthil

  6. I go this error when I ran yum install redis php-pecl-redis

    Error: Package: php-pecl-redis-2.2.7-1.el6.x86_64 (epel)
    Requires: php(api) = 20090626
    Installed: php-common-5.4.41-1.el6.remi.x86_64 (@remi)
    php(api) = 20100412-x86-64
    Available: php-common-5.3.3-38.el6.x86_64 (base)
    php(api) = 20090626
    Available: php-common-5.3.3-40.el6_6.x86_64 (updates)
    php(api) = 20090626
    Error: Package: php-pecl-igbinary-1.2.1-1.el6.x86_64 (epel)
    Requires: php(zend-abi) = 20090626
    Installed: php-common-5.4.41-1.el6.remi.x86_64 (@remi)
    php(zend-abi) = 20100525-x86-64
    Available: php-common-5.3.3-38.el6.x86_64 (base)
    php(zend-abi) = 20090626
    Available: php-common-5.3.3-40.el6_6.x86_64 (updates)
    php(zend-abi) = 20090626
    Error: Package: php-pecl-igbinary-1.2.1-1.el6.x86_64 (epel)
    Requires: php(api) = 20090626
    Installed: php-common-5.4.41-1.el6.remi.x86_64 (@remi)
    php(api) = 20100412-x86-64
    Available: php-common-5.3.3-38.el6.x86_64 (base)
    php(api) = 20090626
    Available: php-common-5.3.3-40.el6_6.x86_64 (updates)
    php(api) = 20090626
    Error: Package: php-pecl-redis-2.2.7-1.el6.x86_64 (epel)
    Requires: php(zend-abi) = 20090626
    Installed: php-common-5.4.41-1.el6.remi.x86_64 (@remi)
    php(zend-abi) = 20100525-x86-64
    Available: php-common-5.3.3-38.el6.x86_64 (base)
    php(zend-abi) = 20090626
    Available: php-common-5.3.3-40.el6_6.x86_64 (updates)
    php(zend-abi) = 20090626
    You could try using –skip-broken to work around the problem
    You could try running: rpm -Va –nofiles –nodigest

    Any suggestions? Please help.

  7. Hi,
    article very helpfull, but I have to clarify one issue,

    Correct configured Magento and Redis will keep /var/session and var/cache catalog empty all the time?

    I don’t know why but I have a lot files inside – few hundreds MB, also via SSH file /var/redis/6379/dump.rdb has few MB.

    Please advise is this normal?

  8. Note – the URL you have for migrateSessions_mysql_redis.php script doesnt work, new working URL is:
    https://raw.githubusercontent.com/colinmollenhour/Cm_RedisSession/master/migrateSessions_mysql_redis.php

    Note2 – the above mentioned script puts the sessions into Redis DB 0, however your sampel config uses Redis DB 2 for sessions. So, you would need to edit the migrateSessions_mysql_redis.php file to use DB 2 instead of 0 for inserting sessions into redis.

  9. Perfect article Marko, Thanks for sharing.

    I have one question, I did my test on non-production machine and tested it with AB with 1000 concurrent connection. i noticed that php-fpm still running many processes and consuming 90% of the processor.

    My question: Shouldn’t Redis reply all the requests if it is to the same URL without passing any to php-fpm (nginx)? So why all this processes php-fpm is running and consuming the processor.

    I can see Redis caching the data by (keys *) from redius-cli but i think it still sending the requests to nginx

  10. Hello

    Can anybody help me with this issue with redis cache .. Thanks in advance.

    There has been an error processing your request

    protocol error, got ‘4’ as reply type byte

    Trace:
    #0 /Sites-Enabled/ZoetisMagento/lib/Optaros/Cache/Backend/Redis.php(79): Redis->select(‘1’)
    #1 /Sites-Enabled/ZoetisMagento/lib/Optaros/Cache/Backend/Redis.php(153): Optaros_Cache_Backend_Redis->getRedis()
    #2 /Sites-Enabled/ZoetisMagento/lib/Zend/Cache/Backend/TwoLevels.php(199): Optaros_Cache_Backend_Redis->save(‘a:4:{s:4:”data”…’, ‘OM_DB_PDO_MYSQL…’, Array, ‘19000’)
    #3 /Sites-Enabled/ZoetisMagento/lib/Zend/Cache/Core.php(390): Zend_Cache_Backend_TwoLevels->save(‘a:16:{s:9:”enti…’, ‘OM_DB_PDO_MYSQL…’, Array, false)
    #4 /Sites-Enabled/ZoetisMagento/lib/Varien/Cache/Core.php(76): Zend_Cache_Core->save(‘a:16:{s:9:”enti…’, ‘DB_PDO_MYSQL_DD…’, Array, false, 8)
    #5 /Sites-Enabled/ZoetisMagento/lib/Varien/Db/Adapter/Pdo/Mysql.php(1470): Varien_Cache_Core->save(‘a:16:{s:9:”enti…’, ‘DB_PDO_MYSQL_DD…’, Array)
    #6 /Sites-Enabled/ZoetisMagento/lib/Varien/Db/Adapter/Pdo/Mysql.php(1577): Varien_Db_Adapter_Pdo_Mysql->saveDdlCache(‘sales_flat_orde…’, 1, Array)
    #7 /Sites-Enabled/ZoetisMagento/app/code/core/Enterprise/SalesArchive/Model/Resource/Setup.php(126): Varien_Db_Adapter_Pdo_Mysql->describeTable(‘sales_flat_orde…’)
    #8 /Sites-Enabled/ZoetisMagento/app/code/core/Enterprise/SalesArchive/Model/Resource/Setup.php(91): Enterprise_SalesArchive_Model_Resource_Setup->_syncTable(‘sales_flat_orde…’, ‘enterprise_sale…’)
    #9 /Sites-Enabled/ZoetisMagento/app/code/core/Enterprise/SalesArchive/Model/Resource/Setup.php(76): Enterprise_SalesArchive_Model_Resource_Setup->_syncArchiveStructure()
    #10 /Sites-Enabled/ZoetisMagento/app/code/core/Mage/Core/Model/Resource/Setup.php(242): Enterprise_SalesArchive_Model_Resource_Setup->afterApplyAllUpdates()
    #11 /Sites-Enabled/ZoetisMagento/app/code/core/Mage/Core/Model/App.php(412): Mage_Core_Model_Resource_Setup::applyAllUpdates()
    #12 /Sites-Enabled/ZoetisMagento/app/code/core/Mage/Core/Model/App.php(338): Mage_Core_Model_App->_initModules()
    #13 /Sites-Enabled/ZoetisMagento/app/Mage.php(640): Mage_Core_Model_App->run(Array)
    #14 /Sites-Enabled/ZoetisMagento/index.php(82): Mage::run(”, ‘store’)
    #15 {main}

    Error log record number: 192021804923

    Thanks
    Nitin Arora

  11. Ubuntu doesn’t have updated repositories of Redis. Just tried method describes and it provides a very old version of redis

  12. Hello,

    Please can someone help me to find the good configuration for magento CE 1.9
    Your configuration is different than the local.xml.additional included in the magento install.
    You write for magento CE 1.9 backend : Cache backend – included, available as Mage_Cache_Backend_Redis
    => in the magento file I have “Cm_Cache_Backend_Redis”
    you have
    in the magento file : 1

    Also if someone can tell me if Cache tags cleanup cron are included in magento 1.9 CE or if I need to download from github and install this cron manually ?

    This is the tutorial for magento 1.8 and upper : http://www.magentocommerce.com/knowledge-base/entry/redis-magento-ce-ee

    they tell just enbale CM_redissession.xml and copy info from local.xml.additional … I’m not an expert in cache management so if someone can confirm what is the good option / config for magento 1.9.0.1 and 1.9.1 CE … thanks a lot for your help ! 🙂

    Also, if I just want to use Redis for Backend (and not for session storage) … can you tell me if I need to enable the CM_redisSession.xml ?

    What is the best choice between :
    – Use redis for backend AND for session storage
    – Use redis for backend and Memcache for session

    Thanks again

  13. I appreciate for your post. It is useful. I followed all steps here, redis/magento is working fine, but I get no positive improvement in performance. My hardware is pretty good Phenom x4 3.4 Ghz, 16 Gb RAM DDR3, SSD, Debian 7.6 out of the box. Server configuration is basic: nginx, php-fpm, mysql. I am using AB to test the improvement in performance. With Redis is a little bit slower. I put back to disk again cache and sessions. Do you have any thoughts? I read that in this configuration Magento doubles as performance. I agree but not in my case.

  14. Hello Marko,

    I am currently using redis for my website. It works fine,except certain scenarios. Checked error log and showing session is getting locked. On refreshing the session. It again start working. Can you please help to resolve this query?

  15. Thanks alot for your documentation, everything works smooth here after following up your manual.

    When you have enabled backend cache, and after that activate session storage. Don’t forget to flush the Redis databases or else session storage won’t work cuz it has local.xml cached.

    My website is much faster, the backend is very fast now and the frontend checkout pages load better. All not full cached pages do load much quicker after installing Redis.

    One question:
    I also have APC running, should I disable this now that Redis is installed?

  16. Hi Marko, Thanks for the article. I have set redis as you described and have seen a list of records when i have run keys * in redis server, but i can’t find any difference in my db load or in site performance, how can i check weather data is served by redis or not?

  17. Hello,

    We run multiple magento installations on our shared servers and We’ve implemented Redis Cache in them. Upon testing the Caching mechanism of Redis Cache and ‘phpRedisAdmin’ (https://github.com/ErikDubbelboer/phpRedisAdmin/), It seems like phpRedisAdmin has access to the Redis DB and it can access the keys of other users. Is it possible to limit its access to the redis database, So that the phpRedisAdmin or any similar application won’t be able to access the DB of Redis Cache/Caching keys of other users.

    I appreciate your thoughts on this.

    Regards,
    Irshad

  18. Hi Marko, thanks for the writeup very useful 🙂

    I notice that my FPC Redis keys are getting blown away relatively often (e.g the number decreases) – this seems strange to me, I would have thought they would at best be recycled after 16 hours (based on thelifetimelimit parameter).

    Are there other smart mechanisms going on here?

    Cheers,
    Dave

  19. Great article!. I have it working in my test dev after reading it. Really well explained and easy to follow. Thanks!

  20. Hi Marko, first thank for your post it is very helpful.
    I would like to go deeper in the association Magento/redis by using master/slave configuration for redis. Such has magento writes on the master and reads from the slave. Do you know any documents specify this configuration.
    Thanks

    Ghislain Nhan

    1. @Ghislain Nhan

      Unfortunately I’m unable to assist you with configuration you have described, but it sounds interesting and if you succeed it would be great if you could drop a few words here, thanks!

      Regards,
      Marko

  21. BTW I’ve also already enabled Cm_RedisSession module editing app/etc/modules/Cm_RedisSession.xml

    (this should probably be added to your article).

    1. @Lrkwz:

      Hello Lrkwz,
      thanks for reporting back with your experiences and I’m glad you got it working. Making sure that Cm_RedisSession is enabled is already a part of this article because I anticipated this could cause some confusion. Unfortunately since Cm_RedisSession works by rewriting db session handler, it has to default to inactive on fresh Magento installations.

      Regards,
      Marko

  22. Thank you for sharing this.
    I’m experiencing a problem using CE 1.8.1.0: session storage does not work as described.
    The core_session is still being populated and KEYS * replies “empty list or set”.

    Thank you
    Luca

  23. @Marko well you have covered a LOT of things here like setting local.xml, session migration and Redis shell tools: for me this is not “concise” 🙂 i think there was still space letf for multiple instances 🙂

    Also, you should cover in part2 (but it’s just a suggestion Marko) a script for garbage collection.

    best regards
    Simone

  24. @Simone:

    Yes, multiple services are recommended by the Redis project and I couldn’t agree more.

    Unfortunately I had to prioritize while writing this article to make it concise because it’s rather lengthily as it is. But thank you for your words, I really appreciate it and I know other readers will too.

    Regards,
    Marko

  25. Hi, thank you for sharing. I think you should mention that Redis is single threded, so to best optimize system, you need to configure a Redis instance for each cache type. Eg if you have a dedicated redis server, and need to store session and cache, one redis service should run on port 6379 and second redis instance should run on 6380 this way you keep datastores separate, you can flush db separatly, and you can have a more optimized cpu/core/redis instance..

    best regards
    Simone

  26. Loved the article. However, on my server I had to use the following command to clone the garbage recovery script:

    git clone git://github.com/samm-git/cm_redis_tools.git

    1. Hello Jean-Paul,
      thanks for sharing your experience. Even though I occasionally have issues with links provided by GitHub, I never got around to find the exact cause to why one URL works and the other doesn’t. For example, clone URL you provided happily works on my local configuration, but at one of the live servers I used for testing it doesn’t. The opposite situation is with the link I used in this article. I suspect this depends on git version and even firewall configuration (because native git protocol uses 9418 port) but honestly I’m not sure. If anyone else has issues with cloning like we do, it’s nice to have an alternative so thanks for contributing, we really appreciate it.

      Regards,
      Marko

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <blockquote cite=""> <code> <del datetime=""> <em> <s> <strike> <strong>. You may use following syntax for source code: <pre><code>$current = "Inchoo";</code></pre>.