http: improve performance for end() with known-length string - #65466
Open
pimterry wants to merge 1 commit into
Open
http: improve performance for end() with known-length string#65466pimterry wants to merge 1 commit into
pimterry wants to merge 1 commit into
Conversation
This boosts RPS performance for the common API case where you call `res.end(data)` with the entire response by up to 9%. Signed-off-by: Tim Perry <pimterry@gmail.com>
Collaborator
|
Review requested:
|
anonrig
approved these changes
Aug 21, 2026
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #65466 +/- ##
==========================================
- Coverage 90.14% 90.13% -0.01%
==========================================
Files 751 751
Lines 252298 252333 +35
Branches 47446 47449 +3
==========================================
+ Hits 227436 227451 +15
- Misses 16175 16186 +11
- Partials 8687 8696 +9
🚀 New features to boost your workflow:
|
lpinca
approved these changes
Aug 22, 2026
efekrskl
approved these changes
Aug 22, 2026
Collaborator
gurgunday
approved these changes
Aug 22, 2026
bjohansebas
approved these changes
Aug 22, 2026
mertcanaltin
approved these changes
Aug 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When you call
end(data)on an outgoing HTTP request, we previously wrote the data, and then ran_send('', ...)just to trigger flushing the headers, which resulted in an extra zero-byte write call and bonus nextTick before'finish'.When the length is known and
content-lengthis used (not chunking, so we don't need a terminator) we can skip this completely: prep the content-length header explicitly, and combine the finish into the existing write step.This drops a nextTick, and goes from 2 write calls to 1 for the very common case of
response.end(data)with a string, and for buffer data goes from 3 writes to 2.In practice, in the tiny benchmark here which I think represents a very common use case (small API responses) I see this boosting HTTP RPS by up to 9% for writes up to 1KB or so. For larger responses the response write time starts to outweigh this, but I still see 3% RPS boost at 16KB. Needs autocannon to hit the rates required, you can test yourself with:
Added a new test confirming the specific details and edge cases this touches, and updated one existing test which specifically asserted that
end(data)triggered two writes, including the empty one.