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 response time vs 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. 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. 

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.

The 

Tuning Advice

TBD

• fast connection between Redis and Runtime
• connection pool size
• tcp keepalive
• disable storing to disk