Wei Kong <wkong@...> writes: > Hi, > > Can someone please help me understand > what the difference is between these two metrics? > See attached chart. We used to rely on session rate to determine when to > autoscale but all of a sudden, the session rate always remains as 1 or 0 > while the current session count goes up to almost 50. > > Thanks, > Wei
I believe session rate is connections or requests (depending on your keepalive setting) per second. current sessions is the current connections active on that frontend/backend/server . You can use the socket to get the full list of active sessions, afaik. So if you are using keepalive you might have sessions open/connected but not sending requests or your machines are overloaded and hanging keeping the sessions open or some other reason the sessions are staying open. You probably don't care what your requests/connections per second are - if your instances can process a request in 23 ms (you can get that from the log) each instance can do 43 rps. If you are generating different dynamic pages/content or if the speed of processing varies, then your rps capacity will vary, so you can't know your exact rps cpacity in a complex dynamic system with many types of requests. But your current session is a good indicator of load that calls for additional instances since many applications have a fairly low capacity for concurrent connections when fully loaded (if you are not using keepalive). I noticed during my testing that any amount of sustained queued requests are a good indicator that additional capacity is required. This seems to be a better indicator than session rate or even current sessions. For instance, I have done quite a bit of testing and found that a fairly complex apache/php/eaccel/smarty/redis/mysql app on a micro EC2 instance, has a max capacity of 3 concurrent connections before overloading. People are shocked at how low that number is (and after they review the config/code/logs find that it is not due to poor code/config), but when there are a constant supply of queued requests, it does not take many to fully load the cpu/resources of EC2 instances. YMMV.
