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:
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
Thank a lot for your idea and suggestion! It definitely shed light on where the
discrepancies come from.
Kindest Regards,
Krum.
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: Friday, February 17, 2012 6:14 PM
To: [email protected]
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
> javax.ws.rs.WebApplicationException 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:
http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/WebApplicationExceptionMapper.java
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.
>
>
