Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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 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 decrease 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 .

...