[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-users] High CPU Load in Jetty 7.6.2 / JDK 1.7
|
Hi Simon,
Comments inline. Thanks for continued interest.
-----Original Message-----
> From: jetty-users-bounces@xxxxxxxxxxx [mailto:jetty-users-bounces@xxxxxxxxxxx] On Behalf Of Simone Bordet
> Sent: Friday, April 27, 2012 1:07 AM
> To: JETTY user mailing list
> Subject: Re: [jetty-users] High CPU Load in Jetty 7.6.2 / JDK 1.7
>
> Hi,
>
> On Fri, Apr 27, 2012 at 01:07, Devon Lazarus <Devon.Lazarus@xxxxxxxxx> wrote:
> > Hi,
> >
> >
> >
> > I just wanted to provide an update on this for the benefit of the list.
> >
> >
> >
> >
[ snipped for brevity ]
> Just to confirm: are you using SSL ?
We are not using SSL for communication between the client and server. We are behind a load balancer that is providing SSL termination services for us. We are, however, using Jetty NIO inside the application to talk to third-party APIs over SLL.
> In 7.6.3 you still have the selector and the acceptor threads that consume most CPU ?
Unfortunately, yes. 99% of the (real) CPU time as viewed through VisualVM using the JMX connectivity enabled within Jetty (start.ini, jetty-jmx.xml).
Is it possible, that VisualVM is misreporting this? Our application actually makes a call out to a third-party API acting as a proxy for our clients. If that thread is stuck in wait() would it show up as CPU time for the selector/acceptor and not thread.wait()? That would also be a problem for us, but a different one than we're researching now.
> Is Jetty behind a HTTP 1.0 proxy ?
> I ask because having the acceptor do so much work seems to indicate that connections
> are opened at a high rate, which may explain the whole thing (HTTP 1.0 requires to
> close connections after each request, which is a performance hit).
No HTTP 1.1 proxy, however...
1) We are opening ton's of connections at a very high rate. We operate a similar application written in C# .NET that processes over 100MM API calls a week. We have attempted a port to Java and are trying to simulate the same load. We are comparing performance between the two and we are at about .5 Java to .NET-- meaning the Java implementation is 1/2 that of the .NET. That isn't right so we're trying to figure out what has happened.
2) Our "web client" is actually an embedded firmware product. Although it makes an HTTP 1.1 request, it closes the connection itself immediately after the last byte of the response has been received. Although this isn't semantically correct from an RFC point of view, the .NET IIS6 implementation does not suffer from the same CPU load issue.
> Simon
