users@jersey.java.net

RE: [Jersey] Custom inject provider

From: Guba, Nicolai <nguba_at_bioware.com>
Date: Tue, 30 Jun 2009 07:06:01 -0700

One thing that we have learned over the years is that it is impossible to predict performance empirically. One needs to measure the application and then compare measurements to determine whether any improvements actually yielded the expected results. You may be surprised what you find at times :) Like Paul mentioned earlier. Data is king!

It must be said however, that we measured the effect of the request being processed by jaxb-json (which uses Jackson) versus 'plain' jersey where we used the java implementation of JSON and hand-crafted a protocol. To be fair, there may be plenty of reasons why this is slower, not just Jackson on it's own. I would arguge that it is a price worth paying though.

Unfortunately I cannot release any source code :( but such test should not be too difficult to set up on your own.

Thank you for the background info in FI. Are there any recommendations for an efficient data format other than JSON or can we say that right now JSON would be our best option?

Happy Hacking!
-- 
   =NPG=
-----Original Message-----
From: Tatu Saloranta [mailto:tsaloranta_at_gmail.com] 
Sent: Tuesday, June 30, 2009 1:52 AM
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] Custom inject provider
On Mon, Jun 29, 2009 at 12:23 PM, Guba, Nicolai<nguba_at_bioware.com> wrote:
> You don't have to use JAXB at all.  You can just obtain the request as String and then unroll your own object.
Or, for better efficiency, InputStream.
> We have actually measured the impact of this and the results have shown about a 16% overhead of Jackson unmarshalling vs the good ol JSONObject (go figure!  I thought Jackson was meant to be quicker).
That would be most unexpected result. :-)
Do you happen to have a simple test case at hand to exhibit this
behavior? Or maybe a code snippet?
And yes, Jackson is meant to be faster. Usually by factor of 4x or 5x,
from feedback I have gotten. I haven't seen any case where default
JSONObject would come anywhere near it, speedwise, so I would be
interested in seeing what gives results you are seeing.,
> If raw protocol speed is of essence, then looking at fast infoset may be a better alternative.  As far as we are concerned, we have benchmarked our request handling in the region of 16-17k requests per second per server---which is most adequate.
From what I have seen, FI is actually not necessarily faster than JSON.
It can be bit faster than plain old textual XML overall (slower to
write == serialize, faster to read), but it's really important to
measure things to know for specific use cases. FI has bit higher
per-invocation overhead it seems, so benefits are bigger for larger
documents.
-+ Tatu +-
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
For additional commands, e-mail: users-help_at_jersey.dev.java.net