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

feat(stream_api): use TCP instead of UDP #8641

Merged
merged 1 commit into from
Apr 6, 2022
Merged

Conversation

flrgh
Copy link
Contributor

@flrgh flrgh commented Apr 5, 2022

This re-implements the stream API with TCP instead of UDP in order to allow for larger response payloads without having to handle chunking/fragmenting things ourselves.

Performance-wise, keep-alive is used to cut down on per-request connection overhead, and the message payload is sent raw instead of being packed/unpacked on either side. I've done some unscientific testing locally with a single-threaded client and an API that simply echoes back the input payload. With a payload size of 8000 (the max of the current implementation) I am getting ~7-8k rps with the current implementation and ~8-9k rps with this new implementation. Things will obviously degrade from there with larger payload sizes, though I don't think I've raised the limit so high as to necessitate further optimizations (let me know if this is an incorrect assumption though).

Error-handling has also been reworked quite a bit, with many code paths that were previously throwing an exception (error()) replaced with logging and/or returning the error to the caller.

Fixes #7377

This re-implements the stream API to use TCP instead of UDP in order to
allow for larger response payloads. Keep-alive is used to cut down on
per-request connection overhead.
@flrgh flrgh force-pushed the fix/stream-api-payload-size branch from d9b18f3 to bf8178e Compare April 5, 2022 22:47
Copy link
Contributor

@javierguerragiraldez javierguerragiraldez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems a valuable improvement. the only suggestion i've put could at best be a marginal advantage. feel free to disregard and/or stash for future experimentation

kong/tools/stream_api.lua Show resolved Hide resolved
@flrgh flrgh merged commit d04aad3 into master Apr 6, 2022
@flrgh flrgh deleted the fix/stream-api-payload-size branch April 6, 2022 20:09
@zhangzerui20
Copy link

@javierguerragiraldez @flrgh Can I merge the changes here into the 2.4.1 and 2.5.1 ?

@flrgh
Copy link
Contributor Author

flrgh commented May 12, 2023

Can I merge the changes here into the 2.4.1 and 2.5.1 ?

@zhangzerui20 sorry it's taken so long to get back to you on this thread!

While there is nothing stopping you from opening up a PR for this, it's unlikely to be accepted, as these are very old branches that we are no longer actively maintaining. The last 2.5.x release was ~1.5 years ago, and the last 2.4.x release was 2 years ago. The only reason I could potentially see us cutting a new 2.4.x or 2.5.x release would be to backport a critical security fix or something of that level of priority.

I think at this stage the effort would be better spent on getting infra upgraded to the 3.x series.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Error: stream_api handler "prometheus" response is 26280 bytes. Only 8000 bytes is supported
4 participants