Magento 2: Redis for Development

While PHP production environments have long made use of extra systems like memcache, varnish, and redis, most successful PHP projects also let developers and technically savvy folks drop an archive of files on a server, point the web server at those files, configure the application to point to a traditional RDMS/database, and have a working application.

After a year or so of life with the Magento 2 non-beta-beta, it’s becoming clearer that this isn’t a priority for Magento’s engineering team. The first run experience remains dismal, and the company’s efforts seem focused on tools for Silicon Vally professionals, such as Docker.

For my on work, I’m still installing Magento directly on my OS X/macOS workstation. With out of the box performance of the file based cache being what it is, I’ve started using redis as Magento’s caching engine for development. This doesn’t solve every performance problem, but browsing around definitely feels faster, which can make all the difference in the world. It’s a pity this is necessary, given that other PHP platforms manage to be performant out of the box – but it’s Magento Inc.’s world, we just live in it.

Quick Redis Notes

If you’re not familiar with redis, it is an “in memory key/value store”. If you’re not familiar with in memory key/value stores, they’re basically

1. A database
2. That can only store a data object by id/key
3. That’s optimized for fast reading and writing directly to the computer’s RAM (i.e. its fast)
4. At the cost of the on-disk representation not being the most up-to-date version of the data (crash or shutdown incorrectly and you might lose something)

I’m using homebrew to install redis

$ brew install redis
...
To restart redis after an upgrade:
  brew services restart redis
Or, if you don't want/need a background service you can just run:
  redis-server /usr/local/etc/redis.conf

By default redis is available on port 6379, at the 127.0.0.1 IP address.

The Magento dev docs site has information on configuring redis as a cache backend. Don’t let the page title fool you – the provided configuration will set redis as both the page-cache backend and Magento’s standard cache backend.

The homebrew package will also give you a redis-cli command.

$ redis-cli
127.0.0.1:6379> 

This CLI client is a little rough around the edges if you’re used to MySQL’s CLI interface, but it will get you what you need for development. If you ever want to peek at your cache keys, you can do so with the KEYS command.

127.0.0.1:6379> KEYS *
 1) "zc:k:314_STRUCTURE_LAYOUT_FRONTEND_STORE1_2DD8D68D60E557251729107544AD7E33E"
 2) "zc:k:314_BLOCK_07A12AFBF27CADF2F437BBE2EDFC1AD1F7EA35A4"
 3) "zc:k:314_LAYOUT_FRONTEND_STORE1_20A98983867A1770682B48D9A0AD63441_PAGE_LAYOUT"

/* ... */

87) "zc:ti:314_DB_DDL"
88) "zc:ti:314_Zend_Locale"

Using the * wildcard with KEYS is probably a bad idea in a production enviornment, but it should be OK for your development setup.

If you’re in a situation where you don’t trust that php bin/magento cache:clean actually cleared your cache, you can remove everything from the redis store with the FLUSHALL command.

127.0.0.1:6379> FLUSHALL
OK

Fetching a key from redis-cli is a little trickier, as each key has an “internal-to-redis” type (hash below)

127.0.0.1:6379> type zc:k:314_STRUCTURE_LAYOUT_FRONTEND_STORE1_2DD8D68D60E557251729107544AD7E33E
hash

and each type requires a different method to display its contents.

127.0.0.1:6379> get zc:k:314_STRUCTURE_LAYOUT_FRONTEND_STORE1_2DD8D68D60E557251729107544AD7E33E
(error) WRONGTYPE Operation against a key holding the wrong kind of value

One last thing to be careful of – don’t add a trailing ; to your key name.

127.0.0.1:6379> [COMMAND] yourkey;

The above command will look for a key named yourkey; – i.e it includes the semi-colon as part of the key name.