This page describes the performance characteristics of a clustered Runtime with the default Redis Key-Value Store Component and provides performance tuning advice.

Memory vs Redis Performance Comparison

When running in a cluster the sessions are read, deserialized, serialized and then written to the Redis on each request. This introduces overhead when compared to storing sessions in the Runtime memory. On the other hand, given a limited amount of memory, storing sessions in Redis has the advantage that not all sessions have to be present in the Runtime memory at the same time, only sessions associated with the requests executing at a particular moment. The following scatter plot illustrates the expected performance as average response time depending on the number of concurrent users (requests):

The actual numbers for response time and number of users will vary from application to application. The plot highlights the following key points:

• Storing sessions in memory will always be faster than storing sessions in Redis, as long as there is sufficient available memory to store the sessions. The difference in response time depends on the application (profile size being the largest factor), but also on a number of settings (see Tuning Advice below). In general, the difference between storing sessions in memory versus storing sessions in Redis should be on the order of a few tens of milliseconds, thus imperceptible to the user.
• When  storing sessions in memory, the amount of available memory has a much larger impact when compared to storing sessions in Redis. When storing sessions in Redis the combination of available memory and load are the deciding factor, since Redis has to keep a session in memory only for the duration of one request. 
• Performance degrades much more quickly when storing sessions in memory. When almost all available memory is used up, the response times will increase dramatically as the garbage collector uses lots of CPU cycles trying and failing to free up memory. In contrast, storing sessions in Redis yields a smaller performance degradation rate. 
• When thinking of number of users concurrently using the application instead of the number of concurrent requests, the Runtime is able to handle close to twice as many users when storing sessions in Redis.

Another important note not visible in the plot is that once an Out Of Memory error occurs, the behaviour of the Runtime is very different:

• when storing sessions in memory, the Out Of Memory state will persist for a longer period. Memory will be freed as sessions expire. Depending on the session timeout setting, this may be several minutes or tens of minutes.
• when storing sessions in Redis, recovery from the Out of Memory state occurs very quickly, as soon as the number of parallel requests drops

A consequence of this is that when saving sessions in Redis, the Runtime is able to recover much faster from sudden usage spikes that cause an Out Of Memory error.

Comparing the performance of memory vs Redis session stores using APDEX under the same conditions yields the following scatter plot:

The key takeaway from this plot is that the performance decrease due to storing sessions in Redis is almost imperceptible by the user.

Tuning Advice

Network Speed

Since sessions are constantly read and written from/to Redis, the network speed between the Runtime and Redis has a significant impact on performance. A 1 Gbps connection is recommended.

Connection Pool Size

The Runtime maintains a pool of connections to Redis. Response times will increase when requests have to wait for connections in the pool to become available. The connection pool size should be increased depending on the expected load per Runtime instance. 

From our observations, the connection pool does not handle sudden increases in load very well. Therefore, we recommend to use a constant pool size by setting the max-active, max-idle and min-idle properties to the same value.

Disable TCP Keepalive in Redis

In order to prevent Redis from closing connections during periods of inactivity, set the tcp-keepalive property to zero in the Redis configuration file.

Consider disabling saving Redis data to disk

By default, Redis saves its data to disk after a certain amount of time and a certain amount of writes have occurred. Under high load (and lots of sessions stored) this may have a negative impact on performance. Consider the risk of losing session data if using a single Redis instance versus the performance impact. If the decision is to keep saving data to disk enabled, then consider disabling the stop-writes-on-bgsave-error setting. Leaving this setting enabled may cause Redis to refuse all writes if saving data to disk fails. This may leave the entire Runtime cluster unuseable until Redis recovers. For more details, consult Redis Persistence .