Redis Stats Test
The Redis Stats test presents to you a plethora of useful metrics on the performance of the Redis server, and quickly points you to the problem areas. With the help of these metrics, you can figure out:
-
Are there more keyspace misses than hits? If so, what could be causing them - expired keys? or evicted keys?
-
Are too many connections contending for the server's resources?
-
Were any connections rejected?
-
Is the network throughput of the server optimal?
-
Are more full synchronizations happening than partial ones?
-
Are partial synchronizations failing?
Target of the test :A Redis server
Agent deploying the test : An internal agent (recommended)
Outputs of the test : One set of results for the target Redis server
Parameters | Description |
---|---|
Test period |
How often should the test be executed |
Host |
The host for which the test is to be configured. |
Port |
The port at which the specified HOST listens. |
Redis Password and Confirm Password |
In some high security environments, a password may have been set for the Redis server, so as to protect it from unauthorized accesses/abuse. If such a password has been set for the monitored Redis server, then specify that password against REDIS PASSWORD. Then, confirm the password by retyping it against CONFIRM PASSWORD. If the Redis server is not password protected, then do not disturb the default setting of this parameter. To determine whether/not the target Redis server is password-protected, do the following:
|
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
Number of lookup of keys per second |
Indicates the number of times the keyspace was looked up for keys every second. |
Number |
|
Number of successful lookup of keys in the database |
Indicates the number of times the keyspace was able to successfully service key requests. |
Number |
Ideally, the value of this measure should be high. |
Number of failed lookup of keys in the database |
Indicates the number of times the keyspace failed to service key requests. |
Number |
Ideally, the value of this measure should be 0 or low. A higher value implies that the keyspace is consistently failing to service requests it receives, because the data being requested is not available in the keyspace. This usually means that one of the following happened:
A lower hit ratio results in larger latency as most of the requests are fetching data from the disk. It indicates that you need to increase the size of the keyspace to improve your application’s performance. |
Total number of expired keys |
Indicates the total number of key expiration events. |
Number |
Normally Redis keys are created without an associated time to live. The key will simply live forever, unless it is removed by the user in an explicit way, for instance using the DEL command. The EXPIRE family of commands is able to associate an expire to a given key, at the cost of some additional memory used by the key. When a key has an expire set, Redis will make sure to remove the key when the specified amount of time elapsed. If the value of the Number of failed lookup of keys in the database is abnormally high, then you may want to check if this measure is reporting a high value as well. If so, then you can conclude that the keyspace misses are being caused by a large number of expired keys. |
Number of deleted keys due to maxmemory limit |
Indicates the number of evicted keys. |
Number |
Typically, Redis automatically evicts keys if its maxmemory configuration setting is violated. If the value of the Number of failed lookup of keys in the database is abnormally high, then you may want to check if this measure is reporting a high value as well. If so, then you can conclude that the keyspace misses are being caused by a large number of evicted keys. |
Total number of connections accepted by the server |
Indicates the total number of connections accepted by the server. |
Number |
An abnormally high value for this measure or a consistent increase in the value of this measure is a cause for concern. Because Redis is single-threaded, one process serves requests from all clients. As the number of clients grows, the percentage of resource time given to each client decreases and each client spends an increasing amount of time waiting for their share of Redis server time. Monitoring the number of clients is important because there may be applications creating client connections that you did not expect or your application may not be efficiently closing unused connections. |
Number of connections rejected because of maxclients limit |
Indicates the number of connections that were rejected |
Number |
Redis server allows you to control the maximum number of client connections for your Redis server with the redis.conf directive “maxclients”. You can also set the maxclients limit from the rediscli by typing config set maxclients <value>. You should set maxclients to between 110% and 150% of your expected peak number of connections, depending on variation in your connections load. Connections that exceed your defined limit will be rejected and closed immediately. Setting a maximum is important for limiting the number of unintended client connections. In addition, because an error message is returned for failed connection attempts, the maxclient limit helps warn you that a significant number of unexpected connections are occurring. Both are important for controlling the total number of connections and ultimately maintaining optimal Redis performance. |
Total number of commands processed by the server |
Indicates the total number of commands processed by the server. |
Number |
This is a good measure of the workload of the server. |
Total net inputs |
Indicates the total number of bytes read from the network. |
MB |
Low values for these measures are indicative of low network throughput.
|
Total net outputs |
Indicates the total number of bytes written to the network. |
MB |
|
Number of commands processed per second |
Indicates the number of commands processed per second. |
Number |
Ideally, the value of this measure should be high, as it indicates that the server has high processing power. |
Total inbound traffic |
Indicates the network's read rate per second. |
Kbps |
|
Total outbound traffic |
Indicates the network's write rate per second. |
Kbps |
|
Number of times slaves have fully synchronized with this master |
Indicates the number of times slaves have fully synchronized with the master. |
Number |
When a partial resynchronization is not possible, the replica will ask for a full resynchronization. This will involve a more complex process in which the master needs to create a snapshot of all its data, send it to the replica, and then continue sending the stream of commands as the dataset changes. |
Number of times partial syncs have completed |
Indicates the number of times partial synchronizations have occurred between slaves and the master. |
Number |
When the link between the master and the replica breaks, for network issues or because a timeout is sensed in the master or the replica, the replica reconnects and attempts to proceed with a partial resynchronization: it means that it will try to just obtain the part of the stream of commands it missed during the disconnection. |
Number of times partial syncs have failed to complete |
Indicates the number of times partial synchronizations have failed. |
Number |
Ideally, the value of this measure should be 0. |
Number of publish/subscribe channels |
Indicates the global number of pub/sub channels with client subscriptions. |
Number |
SUBSCRIBE, UNSUBSCRIBE and PUBLISH implement the Publish/Subscribe messaging paradigm where (citing Wikipedia) senders (publishers) are not programmed to send their messages to specific receivers (subscribers). Rather, published messages are characterized into channels, without knowledge of what (if any) subscribers there may be. Subscribers express interest in one or more channels, and only receive messages that are of interest, without knowledge of what (if any) publishers there are. This decoupling of publishers and subscribers can allow for greater scalability and a more dynamic network topology. |
Number of publish/subscribe patterns |
Indicates the global number of pub/sub patterns with client subscriptions. |
Number |
The Redis Pub/Sub implementation supports pattern matching. Clients may subscribe to glob-style patterns in order to receive all the messages sent to channel names matching a given pattern. |
Main thread running duration |
Indicates the duration of the latest fork operation. |
Microseconds |
A low value is desired for this measure. |
Migrate cached sockets |
Indicates the number of sockets open for MIGRATE purposes. |
Number |
The MIGRATE command atomically transfers a key from a source Redis instance to a destination Redis instance. On success the key is deleted from the original instance and is guaranteed to exist in the target instance. The command is atomic and blocks the two instances for the time required to transfer the key. At any given time the key will appear to exist in a given instance or in the other instance, unless a timeout error occurs. |