Hi, On Fri, Apr 27, 2012 at 01:07, Devon Lazarus <[email protected]> wrote: > Hi, > > > > I just wanted to provide an update on this for the benefit of the list. > > > > We went ahead and switched to the BlockingChannelConnector. Unfortunately, > not only did that not solve our CPU usage issues, but it introduced some > network communication issues. Notably we started seeing ton’s of these in > the log files: > > > > Caused by: org.eclipse.jetty.io.EofException > > > > I tried tuning the tcp driver but that didn’t help at all. Also of note: > we’re using IPv6. I did try to force the JVM to use IPv4 but that didn’t > have an impact either. > > > > There was also a suggestion from the list to try 7.6.3 and we did that too. > We didn’t see any improvement in CPU and we still had the EoF errors. > > > > For now I’ve gone back to the SelectChannelConnector with 7.6.3. The EoF > errors have subsided but our CPU consumption is too high for our liking. > We’ve instrumented the code and are looking at some other options internally > to understand what the issues might be.
Just to confirm: are you using SSL ? In 7.6.3 you still have the selector and the acceptor threads that consume most CPU ? 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). Simon -- http://cometd.org http://intalio.com http://bordet.blogspot.com ---- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz _______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
