Skip to content
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

Remove extra copy of headers/cookies in WebClient #30092

Conversation

yuzawa-san
Copy link
Contributor

When using the reactive webclient with default headers (and cookies) AND headers (and cookies) specified at the request level, there is an additional intermediate map created prior to copying to the final ClientRequest. I believe this can be eliminated in the changes proposed here.

Here is part of the icicle graph of memory allocations:
image

The stuff done in the middle section should go away and be done on the right. Additionally, the fixes in #29972 will improve the forEach and ReadOnlyHttpHeaders performance.

The final copy into the ClientRequest used addAll but I used putAll on the defaults and request-provided values in order to preserve the order of operations. Since it appears that nothing else is setting the headers/cookies on that ClientRequest.Builder using add vs put should not matter.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Mar 9, 2023
@sbrannen sbrannen added in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement labels Mar 9, 2023
@rstoyanchev rstoyanchev self-assigned this Mar 14, 2023
@rstoyanchev rstoyanchev removed the status: waiting-for-triage An issue we've not yet triaged or decided on label Mar 14, 2023
@rstoyanchev rstoyanchev added this to the 6.0.7 milestone Mar 14, 2023
@rstoyanchev rstoyanchev changed the title Remove extra intermediate copy of headers/cookies in WebClient Remove extra copy of headers/cookies in WebClient Mar 14, 2023
rstoyanchev pushed a commit that referenced this pull request Mar 14, 2023
@rstoyanchev
Copy link
Contributor

Thanks for the suggestion. I have added an extra small refactoring, eliminating the intermediate HttpRequest passed into DefaultResponseSpec and passing the HttpMethod and URI instead since that's all that was needed.

@yuzawa-san
Copy link
Contributor Author

yuzawa-san commented Mar 15, 2023

@rstoyanchev thank you, could you please consider the sibling PR to this one #29972? that one has more performance gains.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants