Skip to main content

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

Hi Simone

On Friday, August 9, 2013 at 12:12 PM, Simone Bordet wrote:

On Fri, Aug 9, 2013 at 10:38 AM, Viktor Szathmary <phraktle@xxxxxxxxx> wrote:

Sampling is indeed affected by JVM safe-pointing (mostly
time-to-safe-point) in almost any profiler.
There seems to be a new technique using AsyncGetCallTrace() (see
which is not subject to safe-pointing problems, but AFAIK no current
commercial profiler uses it, apart probably Sun Studio Analyzer (aka
Oracle Solaris Studio) - which works on Linux too.

If you try that, let us know.
I did give this async sampler a shot previously, but it's a bit tricky to manage (far from the comfortable profiling tools :). I couldn't obtain Sun Studio Analyzer.

In any case, it didn't seem to indicate NativeThread.currentThread, but the NIO writes were clearly a hotspot, for example: sun.nio.ch.FileDispatcherImpl.write0 and sun.nio.ch.FileDispatcherImpl.writev0

What certainly seems to be clear and agreed on by all profiling methods is that the org.eclipse.jetty.io.AbstractEndPoint.write (triggered by the flush / close operations) is expensive and that it spends most of its time in native code somewhere – NativeThread.current or FileDispatcherImpl.write*, depending on how much you believe profilers ;)

At this level profiling tools at my disposal make it difficult to trace this further down accurately – but in any case, this is all within the realm of the JDK/pthreads/kernel, so can't really optimize that directly (though it would be nice to understand what's actually happening :). 

Thus my question is more along the lines if there's a way in Jetty to reduce the number of these calls. I'm not familiar enough with the codebase to tell – but it would seem reasonable to combine the last flush and the close operations for example…

Regards,
  Viktor


Back to the top