The Redis Configuration Controls allows experienced users to change a selection of Redis settings so they can tune their deployments to behave exactly as they want them. These aren't for new users to modify without thoroughly researching the consequences and taking care in the process; please consult the linked documentation for each setting before changing it.
The design of our user interface follows the actual
redis.conf configuration file, turning it into an interactive form. That makes it easier to take application recommended configurations and apply them to your own Redis deployment. Under the hood, we handle these new settings by automatically applying them to both nodes of your high availability deployment. There's no need to wait for synchronisation at the Redis level to ensure they are applied and saved.
We'll briefly introduce each setting, but for full details of them, you'll find links to the Redis documentation for many of them by clicking on the blue circled question mark next to its name. As we mentioned, the sections and fields of the interface are modelled on the
redis.conf configuration file and that means, where there isn't a link to the documentation, you can find more information there.
The Configuration Controls can be found in the Compose console for Redis under the Settings tab. At the top of the Settings view are the version and upgrade controls, then the "Redis as a Cache" control and then, below that are the new Configuration Controls. They open with the warning we've just given, that these are expert Redis settings with a link to the example Redis configuration file. Then we're into the various settings groups and settings.
Any changes made in these settings will only be applied when you click Apply Configuration Changes. This will put any changes you have made to the configuration into practice on each of the servers.
The first group of settings concern the Network. This contains
timeout is set to its default value of zero, client connections stay open until they are closed by the client. To ensure idle clients are ejected after some number of seconds, set
timeout to a non-zero value.
While some parts of the network will also step in to disconnect idle connections, a keepalive can be used to send TCP ACKs at regular intervals to keep the connection open. You can set that interval with the
tcp-keepalive setting. The default value is zero, which disables this feature.
This section is slightly different because its
requirepass setting is set outside the Configuration Controls.
The Redis authentication credential is a simple password and this is where it can be set. Clicking on Change will send you to the Overview page where that credential can safely be changed. Be aware that any other settings you may have made in the Configuration Controls will be discarded when you click Change.
This setting lets you directly set the eviction policy. The Redis documentation on eviction policies covers the available settings -
Redis 4.0 adds the
volitile-lfu and the
allkeys-lfu settings. These might provide a better hit/miss ratio depending on your use-case. It is covered in the Redis documentation here.
This setting is changed by switching between Redis Cache and Storage Modes.
There's only one setting in Lua Scripting and it sets the
lua-time-limit. That's the number of milliseconds that a Lua script can run before being kicked into touch by Redis for taking too long. It's a safety feature to stop the system being hogged by badly written loopy scripts. Important fact: This doesn't kill the script, it logs it and tells other clients the system is busy while waiting to be told to kill the script. The default is five seconds which is enormous when you consider a script is supposed to run in a millisecond.
The Slow Query Log feature is where we began. It uses two configuration settings,
slowlog-max-len. More information on slow log configuration and monitoring is available on the Redis Slow Logs page.
Another setting that was previously available is the Event Notification's
notify-keyspace-events. This setting gives you the ability to plug into the changes going inside the database. The feature is called "Keyspace Notifications" and you can read about it in the Redis documentation. The short version of that is you set a configuration variable,
notify-keyspace-events, to a string which represents what events you want to hear about. Setting it to the string "KEA" says you want a stream of all events. You can listen to that stream by connecting to Redis and issuing a
psubscribe command looking for messages with a key pattern of
If this article didn't solve things, summon a human and get some help!
Updated about a year ago