Skip to content

Consider optimizing flush calls in message writers #35427

@dsyer

Description

@dsyer

Flush is expensive generally, and in a scenario where a controller returns a single POJO that Spring renders via a HttpMessageConverter we end up with a double flush - once at the end of the message writer, and once implicitly when the container finishes processing the response. The containers are optimized not to flush if their buffer is empty, but in the case that there are still headers waiting to be flushed (e.g. trailer headers), this ends up almost doubling the cost of request processing. I tried it with a modified message writer (copied all of AbstractGenericHttpMessageConverter and commented out the call to flush) and saw the benefit immediately.

I guess we might have to just flush if we think it might be streaming (i.e. the controller returns a Publisher), even though it still might be inefficient to flush after every message, because whether or not we could improve performance depends on how often they are emitted.

Metadata

Metadata

Assignees

Labels

in: webIssues in web modules (web, webmvc, webflux, websocket)status: waiting-for-triageAn issue we've not yet triaged or decided on

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions