-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Performance enhancement in HttpSessionRequestCache #11666
Conversation
Thanks @ShinDongHun1. Do you have any way to quantify the performance improvement of this change? For example, how much faster is it for 1000 requests, etc.? I'm not sure we would want to push the change if we don't have a good answer for what the improvement/impact actually is, since this change would appear in the release notes. |
@sjohnr Thank you for answer. I tested with 10000 requests after setting the createSessionAllowed attribute to false and 1.5 times faster on average. But the difference is only a few tens of milliseconds. It's a pity that my code won't be reflected with this performance improvement, but I don't think there's any reason not to apply it if there is a better alternative. I don't think my code will be reflected because the performance improvement is so small. :( But I don't think there's any reason not to include better code. I'm sorry I'm not good at English, and thank you so much for your reply! |
No problem, we can try our best to understand each other! I'm really glad you're enjoying contributing!
So are you saying that with 50000 requests, you saw a 2x speed increase per request, for example in 10 milliseconds per request instead of 20 milliseconds? If so, that is definitely worth pursuing!
It doesn't sound small to me! But we'll need to make sure. I'll also see if I can find time to run a few tests and verify your findings. I'll reply back when I've had a chance to look at this deeper. |
umm.. I meant the total time that all requests are processed, not per request Previously, 50000 requests were processed within 90ms in my computer(macbook m1 pro). I tested using 200 threads via Executors.newFixedThreadPool(200). thank you for your reply :) |
Ok. I think it works out about the same either way. It doesn't sound like a lot but 45 ms could be a lot. |
@ShinDongHun1, thanks for your patience. I put together a pretty simple test to measure performance differences with this code change. I tested just the method There were no discernible differences with the default configuration for Before code change:
After code change:
So we save about 1.35 microseconds per request. This is pretty small, but proves that the performance impact is non-negligible. It's worth noting that most applications would use the |
Merged into 5.8.x as 4ff0724 |
savedRequest is only used in conditional statements.
Thus I moved the constructor for DefaultSavedRequest into the conditional statements.
Then it will be only executed when conditions met.
Accordingly, I expect that there are some performance improvements.