cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: REST performance discrepancies between CXF and Jersey
Date Mon, 20 Feb 2012 15:48:49 GMT
On 20/02/12 15:28, Sergey Beryozkin wrote:
> Hi Krum
> On 20/02/12 15:05, Bakalsky, Krum wrote:
>> Hi Sergey,
>> Wow! I tested your idea and it produced dramatically better results!
>> The roundtrip time for 404 requests decreased by a factor of 10 (from
>> 0.500 seconds down to 0.030 seconds). That is a huge success for our
>> investigation, and I believe that our observation is really true that
>> the overhead is spent in the error handling code. Just out of
>> curiosity: with the same SimpleApplicationMapper:
> Thanks for the confirmation, so we've identified the spot where the
> problem is :-)
>> public class SimpleApplicationExceptionMapper implements
>> ExceptionMapper<WebApplicationException> {
>> @Override
>> public Response toResponse(WebApplicationException exception) {
>> return Response.status(404).build();
>> }
>> }
>> Jersey behaved very similarly to CXF in terms of roundtrip time.
>> However, without this class, Jersey performed even faster - most of
>> the times were 10 times faster, i.e. around 0.003 seconds, while in
>> the CXF case ... you already know it :) - 0.500 seconds

Forgot to comment to this one... I think the fact that both frameworks 
show approximately the same time with SimpleApplicationExceptionMapper 
in place and that Jersey scales really well without it is that Jersey 
basically either writes  to HTTP out stream or propagates the exception 
up to the ServletException filter immediately if no custom mapper is 
In case of CXF the immediate propagation will also happen if no custom 
mapper is available. The reason the default WebApplicationException 
Mapper was installed was to do with the fact that few users were not 
quite happy with having to write their custom mappers in order to report 
differently to the exceptions generated at the runtime level or some of 
the providers' level or indeed having to write a filter catching the 
escaped exceptions there...

What I might need to do additionally is to introduce a contextual 
property that will tell the runtime to ignore even the default 
WebApplicationException mapper, for example, when the user wishes to 
get all the exceptions propagated to the filter level, to simplify the 
performance data comparison, etc

Cheers, Sergey

>> Thank a lot for your idea and suggestion! It definitely shed light on
>> where the discrepancies come from.
> I've opened
> I suspect now that it is the specific lines which get the basic warning
> message from the resource bundle are main 'culprits', I guess I will
> just have an internal final static String - will need to experiment a
> bit...It is good even the default providers can be customized/replaced,
> but I'll look into trying to make the default exception mapper
> performing a bit better :-)
> Thanks, Sergey
>> Kindest Regards,
>> Krum.
>> -----Original Message-----
>> From: Sergey Beryozkin []
>> Sent: Friday, February 17, 2012 6:14 PM
>> To:
>> Subject: Re: REST performance discrepancies between CXF and Jersey
>> Hi Krum,
>> On 17/02/12 15:26, Bakalsky, Krum wrote:
>>> Hi to all Apache CXF users!,
>>> I would kindly like to bring to your attention a particular problem
>>> that we are currently being stuck into. We are experimenting with a
>>> simple web application, which exposes its functionality via REST. We
>>> are using JAX-RS/JSON, no SOAP, no JAX-WS. We deploy our application
>>> on top of Tomcat 7, and test both against CXF 2.5.2 and Jersey as
>>> REST frameworks.
>>> For calculating our performance measurements, we simply execute REST
>>> requests, and in the client we measure the time that the roundtrip
>>> takes. Apart from that, on the server side, we measure as well the
>>> time that our REST resource consumes, i.e. the method call time. In
>>> summary, we have some huge differences between CXF and Jersey - in
>>> favor of Jersey being much faster - in the cases where we test
>>> against non-existing resources. In all other cases, the numbers we
>>> got were really very close for the two REST frameworks.
>>> But when testing against non-existing REST paths, the roundtrip time
>>> in CXF case is approximately 0.5 seconds, while in the case of Jersey
>>> it is 0.01 seconds. We think that this is quite strange, and probably
>>> we are not using CXF in its proper configuration. Could you please
>>> give us some hints ? Maybe we have to tune and tweak it a little bit,
>>> so that we get the best out of it.
>>> The server side time, in the case of CXF, is rather small - 0.001
>>> seconds, so we wonder where is that half second spent in ? In our
>>> application logic, in the case when the path is not correct, we throw
>>> and with a debugger we saw that
>>> this exception is getting caught in CXF, and heavily processed
>>> further down the stack.
>>> Are you aware of such kind of issues, with CXF handling the 404
>>> situation in a very heavyweight manner ? Maybe it does some thorough
>>> processing to try to map the URI to some existing REST resource, I
>>> don't know ... maybe performance here could depend on the particular
>>> JSON framework that is being used. ...
>> I suspect it could be the default WebApplicationExceptionMapper which is
>> to blame.
>> In CXF, a given Exception, once wrapped in a Response, is treated like
>> any other regular response, but I'm not sure it would explain the
>> difference.
>> Can you give me a favor please and register a custom
>> WebApplicationException mapper which would only return:
>> Response.status(exception.getStatus()).build() ?
>> Have a look please at the default mapper's code:
>> As you can see, we are trying to go to some length there to figure out
>> what and how to report a given exception and I reckon it all adds up to
>> the response time.
>> Please try eliminating the default mapper and let us know the results
>> Thanks, Sergey
>>> Kindest Regards,
>>> Krum.

Sergey Beryozkin

Talend Community Coders


View raw message