-
Notifications
You must be signed in to change notification settings - Fork 788
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add caching mechanism for the date header value #3303
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. I think akka-http does something similar. Is there any benchmark evidence that this improves things? The implementation itself looks good.
Yes, I tested the improvement with a JMH benchmark and obtained these results:
The benchmark code was this short snippet:
The benchmarked code isn't exactly the same as it creates a new |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The impact in the context of serving a full response will not be as stark as the multiplier in the benchmark, but it should make a positive difference, and it's clearly written.
We could also consider making this a functoin on the Date
header itself, but we're stricter about referential transparency in core, and the F
wrapper would give back some of the gain.
I think we should go with this, and cherry-pick it onto series/0.21.
Cherry-picked for release into 0.21.x. |
I was upgrading the http4s code in the Techempower Benchmark and got curious to see where some of the bottlenecks are.
One of them was the fact that the HTTP Date header is always calculated and rendered for each request. This means that if you receive a lot of requests in a second each time you're going to render the Date header.
To solve this, this PR adds a simple caching mechanism that only renders the date header once in a given second, reusing the same value for all subsequent requests in that same moment.