On 03/06/2016 14:36, Rémy Maucherat wrote: > Hi, > > With direct connect having been hacked in (err, I mean, "implemented"), it > is (a lot) easier to do meaningful performance tests. h2load is a drop in > replacement of ab that uses HTTP/2, and it allowed doing some easy > profiling. > > The good news is that the code seems to be well optimized already with few > visible problems. The only issue is a very heavy sync contention on the > socket wrapper object in Http2UpgradeHandler.writeHeaders and > Http2UpgradeHandler.writeBody.
I suspect that is inevitable given the nature of the test. There is only one connection and if you have 100 streams all trying to write to the one connection at the same time you have to synchronise on something. > The reason for that is when you do: > h2load -c 1 -n 100 http://127.0.0.1:8080/tomcat.gif > It ends up being translated in Tomcat into: process one hundred concurrent > streams over one connection. Although h2load is not real world use, that's > something that would need to be solved as a client can use of a lot of > threads. Hmm. We might be able to do something if we buffer writes on the server side (I'm thinking a buffer for streams to write into with a dedicated thread to do the writing) but I suspect that the bottleneck will quickly switch to the network in that case. > There are two main issues in HTTP/2 that could be improved: > 1) Ideally, there should be a way to limit stream concurrency to some > extent and queue. But then there's a risk to stall a useful stream (that's > where stream priority comes in of course). Not easy. That should already be supported. Currently the default for concurrent streams is unlimited but we can make it whatever we think is reasonable. The HTTP/2 spec suggests it should be no lower than 100. > 2) All reads/writes are blocking mid frame. It's not too bad in practice, > but it's a useless risk, that's where async IO can provide an "easy" > solution using a dedicated NIO2 implementation. They are blocking mid-frame but given the flow control provided by HTTP/2 the risk should be zero unless the client advertises a larger window than it can handle which would be the client's problem in my view. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
