In the last two weeks, WEBD has upgraded two of our big services: Confluence and JIRA. As apart of these upgrades we turned over authentication to CAS, our single-sign-on service. Now users will be able to jump back and forth between Confluence and JIRA without having to login a second time. Confluence now becomes a great place to keep documentation and support for web applications that also employ CAS authentication.
We run a number of applications in Tomcat (both 5.0.x and 5.5.x) and for the most part we’re very happy with the performance we get. There is one time of the year where our CAS (Central Authentication Service) gets killed though, and it’s because of SSL connections. Let me elaborate, it’s because of Tomcat 5.0.x running under JDK 1.4.x. One application for one hour out of the year floods CAS with so many requests that it can’t keep up due to the overhead of SSL. JDK 1.4 just can’t deal with SSL very well, or rather, very quickly. The threads fill up and start blocking connections. In the business we call that LTO (Less Than Optimal).
Now, there are many technical solutions (Tomcat has native APR libraries, we could front with Apache httpd or we have hardware that can do SSL but the latter has security issues) which we never deployed because for 1 hour out of the 8,760 hours in a year we do just fine with the existing setup. Yes, I understand that’s only 99.988% uptime, but still it’s pretty good.
Now, you’re probably thinking to yourself “Where the heck have these guys been? Java 5 gives you a huge performance boost and Java 6 just adds to the gains provided by 5!” We’ve been deploying Java 5 on upgrades and new applications. We just never got to CAS and honestly there was no real need because CAS is so simple and so solid, you rarely think about it once it’s running.
Give me numbers, Mrs. Landingham!
I fired up httperf and grabbed some numbers.
Total: connections 2000 requests 2000 replies 2000 test-duration 83.398 s Connection rate: 24.0 conn/s (41.7 ms/conn, < =311 concurrent connections) Connection time [ms]: min 449.9 avg 6122.5 max 47219.6 median 3891.5 stddev 6211.0 Connection time [ms]: connect 6011.3 Connection length [replies/conn]: 1.000 Request rate: 24.0 req/s (41.7 ms/req)
Total: connections 2000 requests 2000 replies 2000 test-duration 57.203 s Connection rate: 35.0 conn/s (28.6 ms/conn, < =26 concurrent connections) Connection time [ms]: min 79.7 avg 255.5 max 3421.0 median 163.5 stddev 230.4 Connection time [ms]: connect 225.6 Connection length [replies/conn]: 1.000 Request rate: 35.0 req/s (28.6 ms/req)That’s roughly a 28% increase in the time to process a request. Now, we all know that there are lies, damn lies, and statistics. This is by no means an exhaustive breakdown of the differences between SSL performance between these two JVMs. This is simply a small bit of empirical data. That being said, it’s probably the cheapest and easiest performance gain your ever likely to get.
A huge thanks to Andrej Ciho for posting his HOWTO CAS-ify Wordpress MU. This could be a big help for us, and many other institutions that are using CAS.
In an effort to further abstract the CAS Login portion of our Ruby on Rails applications, I’ve taken our CAS Login Module and turned that into a plugin that can be included in any past or present Rails applications and managed separate from the development of the applications themselves. You can read all about how the plugin works and how to use it in your application on the Developer Wiki.
This also marks the beginning of our public Subversion repository allowing other developers to access our code via SVN. Currently, the CASLogin plugin is the only source available and only Web Services has write permissions to the repository.
Links
technorati tags:cas, wiki, plugin, rubyonrails
We now have our LDAP servers running behind a virtual host maintained by a Cisco Systems content switch. This is a very good thing as it should allow us to do LDAP maintenance in the future with minimal to no interruptions. Secure, redundant, fail-over…ahhhh, how sweet it is.
