Kevin J. Jones

Here is some more on JAXB performance, the graph below shows the performance of the JAXB 2.0 Reference implementation and the Apache JaxMe project as the size of a data is increased for a trivial address book mapping. It also shows what happens to the JAXB-RI performance when schema validation is turned on, not a pretty picture. This is better than I had seen elsewhere because at 10k (about 13.5 on the graph) we are getting ~80% of peak performance. Obviously using JAXB with smaller messages or with validation on may be damaging to your applications health. The graph for marshaling is below,  this is a much more healthy for small messages but validation is again very costly.     Profiles for these runs shows that un-marshal performance is being governed by startup time and the maximum speed of the XML parser. When marshaling the parser startup costs are obviously not a factor and so the results are more linear. In either case turning on schema validation has a dramatic effect.  

I have been doing some rough benchmarks on JAXB 2.0 performance and there has to be something wrong. A couple of samples I have tried work out at mapping speeds in the 4-5MBytes/sec range. This is really poor in comparison to the speed of modern XML parsers, even parsing with full schema validation is quicker than this using stock processors.

The WS02 team did some benchmarks a while back that show 3k requests/sec. Despite the claim to the contary this is pretty poor for modern hardware but we will ignore that for now.  What is odd though is throughput is not at all constant, it really degrades with smaller messages which are of course the SOA bread & butter. The small message performance matches what I am seeing. I am guessing there has to be some serious start-up costs in the JAXB 2.0 RI to get this type of profile, either that or the up-scaling of the tests is causing odd things to happen. Time for some more digging I think.