Institutional Knowledge

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.

JDK 1.4.2_06

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)

JDK 1.5.0_15

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.