On Mon, Sep 21, 2020 at 9:31 PM Martin Grigorov <mgrigo...@apache.org> wrote:
> > > 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! > https://github.com/tsenart/vegeta/issues/540 > > >> 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 >> >>
