On 21/09/2020 13:48, Martin Grigorov wrote:
> Hi Remy,
> 
> On Mon, Sep 21, 2020 at 2:56 PM Rémy Maucherat <r...@apache.org> wrote:
> 
> <snip/>
> 
> 
>>> 2020-09-21 14:25:04.850 DEBUG 232086 --- [https-jsse-nio-18080-exec-8]
>>> o.a.coyote.http11.Http11NioProtocol      : Found processor [null] for
>>> socket [org.apache.tomcat.util.net.SecureNioChannel@2b435926
>>> :java.nio.channels.SocketChannel[connected
>>> local=/127.0.0.1:18080 remote=/127.0.0.1:42229]]
>>> 2020-09-21 14:25:04.850 DEBUG 232086 --- [https-jsse-nio-18080-exec-6]
>>> o.a.coyote.http2.Http2UpgradeHandler     : Connection [2]
>>>
>>> java.io.IOException: Unable to unwrap data, invalid status [CLOSED]
>>>         at org.apache.tomcat.util.net
>>> .SecureNioChannel.read(SecureNioChannel.java:766)
>>>         at org.apache.tomcat.util.net
>>>
>> .NioEndpoint$NioSocketWrapper$NioOperationState.run(NioEndpoint.java:1468)
>>>
>>
>> When I tested HTTP/2, I used h2c (unencrypted) to get a better idea at
>> what's going on. Otherwise you don't really know what proportion of TLS or
>> HTTP/2 impacts performance more [and then you have to test more things like
>> OpenSSL, be careful that the ciphers used are the same and equally well
>> optimized in each impl, etc].
>>
>> Then once you feel happy about h2c, you can see how things go with TLS.
>>
> 
> Chris also suggested that TLS might be the problem for the low throughput
> but I get good throughput for both HTTP (15-16 K) and HTTPS (12-13 K
> reqs/s). Only when HTTP2 is enabled it drops. The reason is more clear now
> - it is due to the extra RST packets being sent.
> 
> Vegeta does support h2c! So I can give it a try!

I've just done that. I am seeing the client sending RST_STREAM frames
AFTER the request/response has been processed cleanly.

The RST_STREAM frames are being sent with the CANCEL error. i.e. the
client is no longer interested in reading the response body.

This doesn't make much sense as there is little more than two or three
milliseconds between the start of the request and the RST_STREAM. It
isn't happening due to a timeout. It is also always sent AFTER the
server has sent the complete response (the end of stream flag is set)
and sometimes after the next request has been sent.

However you look at it, this looks like a bug in Vegeta. That doesn't
exclude, of course, the possibility of improving how Tomcat handles
traffic like this.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to