At Rutgers, we would see 5000+ logins in a five minute period with each of the two servers barely reaching 10% CPU utilization (that is with both of them running CAS and Memcache). I believe that was with no noticable latency increase.
There are of course trade offs to each backend storage mechanism you use (as you're finding out :-)) On Thu, Mar 8, 2012 at 3:17 AM, jleleu <[email protected]> wrote: > Hi, > > Just to give you some more figures. > > We are handling ten times more logins at peak hour : 140 k logins with > three servers (Tomcat 6) BUT our tickets storage is Memcached and not a > database. Our CAS servers did not run slowly under load. > We were using Oracle but we couldn't handle so many logins. > > Marvin is right : > - you have to distinguish between logins and service accesses (we have > three to four times more service accesses than logins) > - you have to bench. > > The number of sessions can come into play in a drastic way : as each login > page starts a web session, you can run out off memory very quickly. In our > case, the number of web sessions was such a bottleneck I created a hook to > kill web sessions just after login. > > Best regards, > Jérôme > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
