[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-dev] NIO inefficiency?
|
Your profiler dump gives a hint:
2.4% - org.eclipse.jetty.server.HttpChannel.write
1.5% - org.eclipse.jetty.server.HttpOutput.flush
1.3% - java.util.zip.DeflaterOutputStream.flush
...
If I'm not entirely mistaken, the DeflaterOutputStream does
on-the-fly compression of data, in which case you might be looking at
the overhead from the "Deflate" compression algorithm ? If you look
further down the graph I wouldn't be surprised if that's seeping
through on several of the methods ?
Kristian
2013/8/9 Viktor Szathmary <phraktle@xxxxxxxxx>:
> 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
>
