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)

1. User names were going from an old 8-character limited shellid to our user friendly LDAP uids.
2. Going from Solaris to Linux

For the first one, there was some sysadmin magic done with the user/group creation on the new system. This allowed the uid to change, but file and group ownerships to survive the migration. But because the uid was changing we also had to redirect ~ directories from old to new.

The second caused a lot of little problems. Binaries that people had hard coded into scripts were not where they were expected to be. Linux has a lot of stuff in /bin that Solaris has in /usr/bin, like ls. I know, who would hard code the location to ls? People do. A few strategically placed symbolic links solved the majority of these issues.

The one thing that we didn’t account for was the difference in the sshd server key. That caused a lot of problems for the help desk at first. Things have calmed down now and overall the migration went pretty well. Users can now authenticate with the LDAP username and password (which is nice). We now have the ability to start thinking about what kind of services Apache will allow us to offer to our users.

The Magic 8 Ball says “Outlook Good.”

Omni presently has no user interface or logic controlling the handling of information. It’s just models, associations, and tests. It’ll be interesting to see how big it will grow over the next couple of weeks.