Re: [jetty-dev] NIO inefficiency?

[Simone Bordet <sbordet@xxxxxxxxxxx>]

Hi,

On Fri, Aug 9, 2013 at 3:55 PM, Viktor Szathmary <phraktle@xxxxxxxxx> wrote:
> Hi Simone,
>
> On Friday, August 9, 2013 at 3:22 PM, Simone Bordet wrote:
>
> On Fri, Aug 9, 2013 at 3:13 PM, Viktor Szathmary <phraktle@xxxxxxxxx> wrote:
>
> Wouldn't the following in HttpOutput.close do a write w/ empty buffer
> explicitly?
>
> if (BufferUtil.hasContent(_aggregate))
> _channel.write(_aggregate, !_channel.getResponse().isIncluding());
> else
> _channel.write(BufferUtil.EMPTY_BUFFER,
> !_channel.getResponse().isIncluding());
>
>
> No. Member "_channel" is Jetty's HttpChannel, not a SocketChannel.
> If you follow all the way through, you'll see we skip SocketChannel
> writes for empty buffers.
>
> I see both of these paths below taken (on v9.0.4), which seems to imply that
> there are two writes to the SocketChannel: first on flush followed by one on
> close. You are also right – the buffer is not empty then (via
> HttpOutput.close:117, so BufferUtil.hasContent(_aggregate) == true)
>
> But should the _aggregate not be empty already? We have just flushed to the
> NIO buffer…
>
>
> sun.nio.ch.SocketChannelImpl.write:496
> org.eclipse.jetty.io.ChannelEndPoint.flush:167
> org.eclipse.jetty.io.WriteFlusher.write:335
> org.eclipse.jetty.io.AbstractEndPoint.write:125
> org.eclipse.jetty.server.HttpConnection$CommitCallback.process:683
> org.eclipse.jetty.util.IteratingCallback.iterate:79
> org.eclipse.jetty.server.HttpConnection.send:344
> org.eclipse.jetty.server.HttpChannel.sendResponse:630
> org.eclipse.jetty.server.HttpChannel.write:665
> org.eclipse.jetty.server.HttpOutput.flush:151
> java.util.zip.DeflaterOutputStream.flush:282
> org.eclipse.jetty.servlets.gzip.AbstractCompressedStream.flush:125
> sun.nio.cs.StreamEncoder.implFlush:297
> sun.nio.cs.StreamEncoder.flush:141
> java.io.OutputStreamWriter.flush:229
> java.io.PrintWriter.flush:320
> org.eclipse.jetty.servlets.gzip.CompressedResponseWrapper.finish:343
> org.eclipse.jetty.servlets.GzipFilter.doFilter:364
>
> and
>
> sun.nio.ch.SocketChannelImpl.write:463
> org.eclipse.jetty.io.AbstractEndPoint.write:125
> org.eclipse.jetty.server.HttpConnection$ContentCallback.process:781
> org.eclipse.jetty.util.IteratingCallback.iterate:79
> org.eclipse.jetty.server.HttpConnection.send:351
> org.eclipse.jetty.server.HttpChannel.sendResponse:635
> org.eclipse.jetty.server.HttpChannel.write:665
> org.eclipse.jetty.server.HttpOutput.close:117
> java.util.zip.DeflaterOutputStream.close:241
> org.eclipse.jetty.servlets.gzip.AbstractCompressedStream.finish:191
> org.eclipse.jetty.servlets.GzipFilter$1$1.finish:500
> org.eclipse.jetty.servlets.gzip.CompressedResponseWrapper.finish:345
> org.eclipse.jetty.servlets.GzipFilter.doFilter:364

The 2 writes come from different callbacks: the CommitCallback wrote
the HTTP headers and some content, and the ContentCallback wrote some
of the content.
There is not even the guarantee they come from the same request, so
it's difficult to say whether we can optimize something.
It is all normal and without knowing exactly the whole code, there is
little more I can say.
If you think we can improve, we'll gladly accept a patch, but we need
a more detailed analysis (basically, a patch).

Thanks !

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
http://intalio.com
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.