Mission Data Blog
Louisville-based Web Development & Software Engineering

Updated Rails 1.2 performance numbers have been released. While these number look pretty good it is hard to get a good idea of exactly what the performance of Rails is. A couple of other benchmarks that include Rails such as performance tests for 6 frameworks and Grails vs Rails benchmarks show a different picture. Both of these come up with much worse performance than the first. Maybe the issue is that the second two benchmarks are using Apache ab but the first uses a new version of rails bench. Of course most people probably aren’t that worried about the benchmarks that much because you can find ways to make anything fast as shown with Rails doing 4000 requests a second.

Everyone has probably noticed this already but the old is new again cycle for “online” desktop apps has been shortening at a rapid pace. Everywhere you turn you see people talking about offline and online apps and what should be online vs offline. If you take your time machine back you would see something like the following timeline:

• 1970s 3270
• 1980s X terminal
• 1990s Java applets
• 2000 Flash
• 2005 Ajax

Up until about 2000 it was taking 10 years to cycle from “we want everything on our desktop” to “we want everything on the server”. Now the cycle seems to have sped up to every year and then to constant. A couple recent examples of new faces on this old idea are Adobe’s Apollo and Joyent’s Slingshot.

Fundamentally not much has changed from the 1970s. The goal is to centralize computing resources into one place (in the simple view of things) and make issues like software deployment easier.The main difference now is that the industry has come to the point where there isn’t any turning back and everyone has bought on to the need and usefulness of online apps. The main sticking point seems to be finding a way to resolve issues that come up from users being disconnected from time to time. I’ll bet that one won’t be fully resolved until you have connectivity anywhere and everywhere you go.

By default tomcat doesn’t UTF-8 encode get parameters like it does post parameters. This doesn’t seem to be the case with other application servers. So before you get yourself into trouble with your internationalized web application, make sure you make this change.

Our project has entered the stage where we start tuning the data access to improve performance. This project uses Hibernate to access a AS400/iSeries system via the JT400 JDBC driver. My prior experience using the SQL Server
database introduced me to Microsoft’s Query Analyzer, which is a nice tool for identifying where you need to index the database. A bit of searching turned up an IBM tool called Visual Explain that fits the same need. The sysadmin started the profiling tool against my connection, and I ran through a standard usage scenario in our application. Visual Explain showed each query, how long it took, the access strategy, and recommended indexes. This kind of tool is absolutely essential for database performance tuning.

The second important item we learned from this process is the performance difference between a true SQL index on the iSeries and a keyed logical index. From iSeries V4R2 on, SQL indexes have page sizes of 64k. By comparison, a DDS logical will max out at 32k, and will typically be much smaller. The performance is so much better that our customer is converting all all their DDS logical indexes to SQL, even if only their legacy RPG applications use it. This IBM document has a good discussion of this issue.

When you’re using Hibernate and are mapping to properties, keep your getters and setters as simple and self-contained as possible. The receiver being initialized may not have any other properties set, and the value being passed may not be fully initialized yet, either.

If you don’t respect these two possibilities, then you will get bit in the butt alot, when you least expect it. To be fair, these situations can happen whether you’re using Hibernate or not, but when we first started using the framework we made lots of assumptions.

Here is a completely ridiculous example that violates the above restrictions:
Read the rest of this entry »

We were helping a client push more data through their apache/tomcat web application running on a Solaris box and decided to switch from the process (prefork) to the threaded(worker) processing model. When we fired up the new apache we started getting errors like these:

[emerg] (45)Deadlock situation detected/avoided: apr_proc_mutex_lock failed. Attempting to shutdown process gracefully.

Not good. After a little digging we found that the default AcceptMutex switched from pthread to fcntl between apache 2.0.49 and 2.0.52.

Adding:

AcceptMutex pthread

to httpd.conf cleared up the errors and we’ve had smooth sailing ever since.

I was tickled when I ran across the GoogleLookup and GoogleFinance functions in Google Spreadsheets. I was very tickled when I found there was a REST API for interacting with the spreadsheets.

So not only can you lookup the current volume of Google stock in a spreadsheet (=GoogleFinance(”GOOG”, “volume”)) or find out Roger Clemens’s ERA (=GoogleLookup(”Roger Clemens”,”earned run average”)) you can access those values real time using an open API. I cobbled together a quick ruby program that can retrieve values from a private or public (published) Google spreadsheet.

Read the rest of this entry »

Steven pointed out that someone was looking for a way to stream to S3 using PHP and said I should figure out how to get it going. Since he made a patch to let you stream data with Ruby using S3 I figured I should do one for PHP. There may be better ways of doing this but since I’ve already done it with C using curl I figured that would be the fastest way.
Read the rest of this entry »

The recently released IE7 supports a native XMLHTTPRequest object. On the surface this can be considered a good thing and should be commended. However, to the people that erroneously (in hindsight) assumed that…

window.XMLHttpRequest == ! (not) IE

…they are in for some strange behavior (here, here, here, and here for example).

The problem occurs when the code is optimized for non-IE browsers and does not recreate the XMLHTTPRequest object on each event. Back when “window.XMLHttpRequest == !IE” was true, this code worked as expected: IE browsers created a new XMLHttpRequest object on each event and non-IE browsers reused the same XMLHttpRequest object. Now IE7 will correctly process the first event but then fails on the second (and subsequent) requests because you still can’t reuse XMLHttpRequest objects.

We chose to just remove the optimization all together and recreate the object on each event for all browsers. Others may wish to come up with some other check that will allow them to keep it.

In an earlier post, we detailed a method for removing stale Rails session files. In more recent version of Rails, there is a Rake task built in for this administration task.

rake tmp:sessions:clear # Clears all files in tmp/sessions