CodeIgniter 3 Redis Backed Sessions Performance and Scalability

Question

I am going to be using aws elasticache Redis for my codeigniter 3 application. I get a fair amount of traffic and am wondering if there is anything I need to be on the lookout for in terms of setup? I get 1700 requets a minute at peek and would be using this for php sessions. I am wonder what elastic cache instance size will work (AWS)

I am moving away from database-backed sessions as that is causing issues with GET_LOCK causing a lot of connections to pile up.

Based on my initial testing it seems to work great and fast. I did a query of the size of sessions tables (Multiple app instances) and I had 100MB in session data.

Answer 1

I did something similar with tomcat / java based app hosted in aws where we moved away from DynamoDB based session management to AWS managed memcached. Below are some recommendations I could offer based on my experience.

1. Setup Automatic failover: Since DynamoDB was a managed service we didn't have to worry about failover / redundancy. But with managed elasticache you have enable redundancy and multi-az replication as it is not there by default. If you want to maintain a seamless user experience when your redis node fails over, you make sure you enable Multi-AZ with automatic failover on your Redis cluster.

2. Choosing the instance size

   Reads: You get 1700 request per minute at peak time. Let's say during peak second you get around 1700 / 60 = ~30 requests per second, which is the minimum read throughput the selected elasticache instance should be able to handle.

   Writes: You haven't mentioned any information on how many new users are logging in but I think it's safe to assume it's not going to nearly as high as reads. Writes can be managed easily if you are flexible at managing the session length. For now it's safe to assume it is going to be less than read throughput.

   Which means you can get away with using cache.t3.small (with Multi-AZ with automatic failover) which has 2vCPUs and 1.37GB sufficient enough to accommodate your throughput and 100MB session storage needs.

3. Selecting correct cache rotation strategy: You want to know if the cache is correctly rotated and what happens to the user performance when the elasticache saturates. Make sure to add correct TTL, which matches your session length.

4. Know the limits and bottlenecks: Make sure you load test the app before pushing this change live. a) Understand what current login requests your app can handle as-is vs after moving to elasticache. Have a upgrade strategy ready in case the traffic grows. b) verify end-user impact when happens when the cache expires c) verify the impact on new logins when the cache is full in elasticache

5. Setup monitoring and alerts: setup monitoring for at least for elasticache fails over signal and when elasticache latency starts goes beyond an acceptable threshold.