Mark,
On 7/24/24 02:27, Mark Thomas wrote:
On 23/07/2024 21:30, Christopher Schultz wrote:
Mark,
On 7/23/24 13:13, Mark Thomas wrote:
Prompted by some folks at $dayjob, I have been looking at the
performance of Tomcat's HTTP/2 implementation using [1]
Initially, I was seeing ~79k req/s.
Restoring lazy init for the StreamInputBuffer increased that to ~106k
req/s.
O_O
Moving the HttpParser from Processor to Protocol increased that to
~108k req/s.
Now I am looking at recycling and reusing the coyote request and
response. That increases throughput to 124k req/s.
This information would be good to put (with a datestamp and
environmental details) into the documentation for discardFacades
and/or similar capabilities.
In Bratislava, we idly speculated that "throwing those objects away
should not affect performance much and improve security" but if it
really is a 15% speed improvement, it might be really critical for
some applications.
It really does depend on which objects you are talking about. Looking at
the flame graph for HTTP/2, it appears that the objects that require the
creation of buffers are the expensive ones to create. I thought we were
talking about the (inexpensive) facades in Bratislava.
Someone (I forget who) tested the performance impact of not recycling
the processors and it was horrible.
Given the significant performance increase I am considering the
following:
- switching HTTP/2 to recycle and reuse coyote request and response
objects by default
Note that we just changed that default in the other direction for
HTTP/1.1. I think we should probably be consistent.
I think you might be getting your objects mixed up.
Indeed. I was thinking we were freeing all objects and not just the facades.
There are three sets:
a) coyote request/response
b) catalina request/response
c) catalina request/response facade
Currently HTTP/2 recreates all of the above for every stream.
HTTP/1.1 always recycles and re-uses a) and b). It is c) that we changed
to always create new objects by default for 9.0.x (to align with 10.1.x
and 11.0.x).
Ack.
This proposal would align HTTP/2 with HTTP/1.1 and recycle and re-use a)
and b) by default but with an option to re-create every time (mainly in
case there is a regression due to an application and/or Tomcat issue).
Okay than I'm +1 because that actually aligns entirely with our recent
decision, except that it's not possible to re-use facades at all which
I'm okay with.
- providing an option to restore the current behaviour of creating a new
coyote request and response object for every HTTP/2 stream
+1 but with a different default.
If that is for alignment with HTTP/1.1 then I disagree. We should
recycle and re-use a) and b). If it is to avoid possible regressions
then I think there is a discussion to be had due to the the performance
benefits vs regression risk trade off.
+1
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
