Brian,
if your database isn't the only performance issue you can also look into
some other performance killers on the cas server itself:
SSL termination:
* Choosing the right crypto termination (Tomcat navtive java vs. apr
termination vs. apache termination). I have seen huge difference since
the apr libs are also faster in the setup of connections.
* Setting the right ssl cyphers [1]. The difference AES128 with (AES-NI
hardware accelleration is massive) vs the old (default) 3DES.
Limit the amount of HTTP requests or traffic generated per Page hit. I
usually use ylow [2] to get a good picture of what is actually going on.
It's usually not much effort to get any cas server in the 90+ score
range. Some of the items are quiet effective:
* I have seen some good effects on the login page by offloading all
static stuff to another cookieless subdomain on another lean webserver
(nginx, lighttpd). This limits the cas servers work to the actual login
or other validation pages. A single impression goes down for the login
page from 5+ (depends on your customization) requests to 1.
* You can apply more "expiration" and "cache control" filters on other
webservers which can actually prevent users from requesting all
js/css/images every day. SSL content is normally not cached in the
clients disk cache which is the only really relevant cache for cas since
a normal user will see the login page once per browser session.
* Since the CAS login page is very small it's usually not a big job to
optimize every single component. (minify js, images, css etc.)
This will probably not give you the big benefits your are looking for on
the backend but i have had some great success bringing down the overall
tomcat load.
Regards,
Joachim
[1] http://zombe.es/post/4078724716/openssl-cipher-selection
[2] http://developer.yahoo.com/yslow/
On 08.03.2012 16:04, Bryan E. Wooten wrote:
Thanks all for the feedback. It looks like management is going allocate
some time so I can do some benchmarking and tuning.
I think I am going to take this opportunity to completely revamp the
infrastructure.
1.Replace Sun Appserver reverse proxy with Apache.
2.Deploy CAS on Tomcat instead of Glassfish
3.Run everything on Redhat instead of Solaris
4.Run everything on VMs for testing and then move to dedicated servers
for production.
*From:*Scott Battaglia [mailto:[email protected]]
*Sent:* Thursday, March 08, 2012 7:08 AM
*To:* [email protected]
*Subject:* Re: [cas-user] Stress testing CAS in production
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]
<mailto:[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]
<mailto:[email protected]> as: [email protected]
<mailto:[email protected]>
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed [email protected]
<mailto:[email protected]> as:[email protected]
<mailto:[email protected]>
To unsubscribe, change settings or access archives,
seehttp://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
--
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
