-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
add twisted gateway server #9834
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
Conversation
S3 Image Test Results (AMD64 / ARM64) 2 files 2 suites 3m 17s ⏱️ Results for commit 1e99f51. ♻️ This comment has been updated with latest results. |
LocalStack Community integration with Pro 2 files ±0 2 suites ±0 1h 33m 0s ⏱️ + 5m 36s Results for commit ec1f1db. ± Comparison against base commit 87f747f. This pull request removes 2 and adds 1 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
This reverts commit 5ada168.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! This looks nice, and the gain in throughput looks really good. Also, from my benchmarks when using concurrency, running as much requests as we could we 25 client threads, Hypercorn would timeout for 9 requests and slow down everything; this issue is not present with Twisted, boosting the throughput by x2. With no concurrency (client thread = 1), the throughput is x8 for S3 (!!!) because of the close header fix I believe?
Anyway, this looks pretty good, thanks a lot for digging into this and all those fix to make it work with our Gateway.
I just have a general comment about it, as I was looking into how to add a new server implementation myself:
For Hypercorn, it seems we have all of the actual implementation in 2 places: aws.serving.hypercorn, and http.hypercorn.
Also, for example in our test_gateway.py, we directly use HypercornServer. For Cloudfront, we still use it as well, and for the EC2 metadata instance as well.
Should we centralize it somehow? It starts to feel a bit spread out to me and I'm a bit confused about it. Maybe I'm lacking context on it?
I think most of the implementation of the twisted server is in serving.twisted, but for werkzeug it's split between aws.serving.werkzeug and directly in aws.serving.edge.
And for Hypercorn it's in http.hypercorn.
Maybe something to do in a follow up PR? What do you think?
|
thanks for the review ben!
you raised some great points that i noticed before as well
definitely something for one or more follow-up PRs! |
alexrashed
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, this is really an awesome change! The server is well abstracted, and the performance tests are promising a huge performance bump! 📈 💯
This is already looking great, and is imho ready to get into master as an opt-in feature with the current limitations. Especially the websocket integration is currently not being used anyways (but will be super valuable f.e. for the next iteration of API GW). And the discussion above is a perfect opportunity to push rolo even further and increase the separation between localstack and its serving infrastructure.
The coverage of this code is great when considering that this is replacing the one server which handles all connections. 🚀
It seems that there might a small issue left with a logged KeyError on startup when being integrated with LocalStack Pro (see comment).
Given that we had issues with these integration tests recently (not properly executing the tests against the correct target), I wonder if there might be some test issues in downstream projects? Are there test runs against this PR?
Besides that, I only had two questions on small changes in the tests (concerning the header casing and the connection handling), just to make sure that all assumptions are clear.
Motivation
We've had several performance and concurrency issues related to hypercorn in the past.
Twisted is one of the few frameworks that satisfies our peculiar requirements of HTTP/2 and WebSocket support, while also not relying on asyncio. This PR adds a way to serve our
Gatewaythrough twisted, thereby completely foregoing our asgi/wsgi bridge. Overall we have seen that this leads on average to around 2X throughput improvement, or more in some cases (@bentsku did some amazing benchmarks already!).A few peculiarities:
Changes
GATEWAY_SERVER=twistedConnection: closeheader is now only forced whenGATEWAY_SERVER == "hypercorn"Benchmarks
Here are some selected benchmarks that @bentsku ran. More can be found in notion
TODO
What's left to do:
Websocketsgoing to do websockets in a second iterationGATEWAY_SERVERback to hypercorn after review