On Mon, Sep 21, 2020 at 5:52 PM Mark Thomas <ma...@apache.org> wrote:
> 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 > I will contact the Vegeta community! > 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 > >
