Posted by mkarg
on January 3, 2010 at 8:27 AM PST
I used my free day to do some more performance benchmarking using EJB 3.0 and WebServices...
I used my free day to do some more performance benchmarking using EJB 3.0 and WebServices.
As I wrote in my last blog entry on this topic, I was astonished what performance is possible even in a VM on my cheat laptop. But now I invested some more time to tune my laptop (running JkDefrag gave its disk an amazing push) and do an optimization in the application itself: Using precompiled queries (so-called "named queries" in JPA) instead of dynamic queries. My idea was that a precompiled query should run much faster since the machine can spare the time for parsing the JPA-QL string. In addition, I changed the benchmarking tool that I wrote to use multiple threads to simulate five clients instead of only one, and to run 50.000 loops to remove Java's typical warmup delay. This should better simulate the real world.
Actually it seems that these optimizations are very beneficial to the overall performance, as the current version of the benchmark shows:
- 200 "senseless" calls (no serverside workload, just an empty SOAP roundtrip) need half a second. While this is an acceptable (and taking into account the fact that extensive XML parsing is done for the WebService, quite impressive) number, compared to the following numbers shows that half the time of virtually each method call, is eaten up by "beeing a WebService" itself.
- 200 "INSERTs" (using JPA via SOAP) need less than one second. For our purposes, this is a good value taking into account the fact that still this is a VM on a laptop, not a server with a RAID 5 or something. It is "just" double the time of an empty roundtrip.
- 200 "UPDATEs" (using JPA via SOAP) need one and a half second. While that number still is ok, I am a bit disappointed the UPDATEs need so much longer than INSERTs. In fact I have not found out a good argument why that is the case.
- 200 "SELECTs" (i. e. one SELECT and then iterating over 200 rows) need just 0.02s! Quite impressive, indeed. I first thought there is a bug, but it is really that fast.
BTW, I also checked another thing. JPA allows to select different types of automatic ID generation. I tried out two of them and benachmarked using IDENTITY columns compared to TABLE. To make it short, both are equal. There is no performance difference. Strange, but true.