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
Thank a lot for your idea and suggestion! It definitely shed light on where the
discrepancies come from.
I've opened
https://issues.apache.org/jira/browse/CXF-4121
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 [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.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com