Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] NIO inefficiency?


Viktor,

firstly thanks for starting this thread.   We've put a lot of changes into the IO layer for 9.0.x and even more for 9.1.x, but have not really had a chance yet to dive in with a profiler to see where the fat is (At least not since the 9.0.M0 stage when we solved some mechanical sympathy issues and ensured that we were faster than jetty 8 ).    So it is very timely indeed, as we intend to spend the next few weeks looking for fat to trim.

However, I would suggest at this stage, effort is probably best spent on 9.1.x.   I restructured 9.0.x IO with the servlet 3.1 asynchronous IO in mind (hence classes like IteratingCallback), but the refactor was only completed in 9.1 and we have more flexibility to change code there without accidentally breaking the servlet 3.1 APIs.

Can you briefly describe the kind of load you are sending the server?  lots of pipelined requests? lots of connections? long held connections?

cheers






 


On 9 August 2013 16:36, Viktor Szathmary <phraktle@xxxxxxxxx> wrote:
Hi,

While profiling a high-traffic server, I have noticed the following hotspot and wanted to get your analysis:

5.2%  - sun.nio.ch.NativeThread.current
  3.2%  - sun.nio.ch.SocketChannelImpl.write
    3.2%  - org.eclipse.jetty.io.AbstractEndPoint.write
    2.4%  - org.eclipse.jetty.server.HttpConnection$CommitCallback.process
      2.4%  - org.eclipse.jetty.util.IteratingCallback.iterate
      2.4%  - org.eclipse.jetty.server.HttpConnection.send
      2.4%  - org.eclipse.jetty.server.HttpChannel.sendResponse
      2.4%  - org.eclipse.jetty.server.HttpChannel.write
        1.5%  - org.eclipse.jetty.server.HttpOutput.flush
          1.3%  - java.util.zip.DeflaterOutputStream.flush
            ...
        0.9%  - org.eclipse.jetty.server.HttpOutput.close
          ...
    0.8%  - org.eclipse.jetty.server.HttpConnection$ContentCallback.process
      ...
  2.0%  - sun.nio.ch.SocketChannelImpl.read
    ...


So basically the read/write/flush operations seem to be burning a whole lot of time in NativeThread.current (= pthread_self on Linux), which doesn't seem reasonable. Do you have any thoughts on why this is the case and if there are alternative approaches to reduce / avoid this?  (e.g. combining the last flush and close?)

Regards,
  Viktor


_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-dev



Back to the top