Page History

...

• 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:

...

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 Runtime maintains a pool of connections to Redis. Response times decrease 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. 

...

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 .