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

Discussion: should there be a way to set early socket options in the high-level interface? #281

Open
njsmith opened this issue Aug 11, 2017 · 2 comments

Comments

@njsmith
Copy link
Member

njsmith commented Aug 11, 2017

Specifically, should there be a way to issue arbitrary setsockopt calls in open_tcp_stream and open_tcp_listeners, before the socket is bound by calling connect or bind?

For example, you might want to set SO_REUSEPORT.

The argument against would be that this makes the API more complicated for an obscure and rarely used feature that's better handled by dropping down to the socket layer.

OTOH the high-level API has some actual value in it; dropping down to the socket layer while replicated its functionality is not trivial.

@njsmith
Copy link
Member Author

njsmith commented Dec 7, 2017

Added the asyncio feature parity label because asyncio does have a reuse_port option to their create_server.

@Badg
Copy link

Badg commented Nov 10, 2022

For what it's worth, I just ran into a use case, though it is probably indeed uncommon (at least based on how difficult it was to find google results about whether or not this is even a good idea). Specifically:

  • I want to EC2 directly, so I have flexibility in both cost control and performance.
  • I want a particuar deployment config to be flexible. So I could vertically scale the instance as needed, increasing or decreasing the number of vCPUs as required (in addition to horizontal scaling) -- which also implies increasing or decreasing the number of running server processes on the instance.
  • I don't want to fiddle with the app config or the underlying image when vertically scaling. Ideally that would mean controlling the number of processes to start by something simple, like, say, an environment variable.
  • I want the upstream network setup to be simple; I don't want to need to have the load balancer targeting a variable number of ports or something crazy. I really want to just use a stock AWS ALB and be done with it.

The thought that occurred to me is that I could:

  1. Load balancer points to an autoscaling group, routing to a single, constant port (eg 8000)
  2. Assign a tag to the autoscaling group that defines the target number of processes
  3. Propagate this tag to the instance
  4. Load the tag from the AWS metadata service as part of a parent systemd task, determining how many processes to start
  5. The parent systemd task starts X child tasks based on that
  6. Each child task sets SO_REUSEPORT

Then, when I want to vertically scale, I can simply create a new autoscaling group. This is probably the essential complexity anyways, since that's where I would want to be specifying the different instance size regardless. And this would give me (I think) a relatively elegant way of tuning vertical-vs-horizontal scaling, which would allow me to control for redundancy vs performance vs cost.

But then there's one hiccup in this whole thing: I also want to use trio!

That being said: I've been using hypercorn as my ASGI server (side note, is there another ASGI server that supports trio?), and hypercorn actually wraps the socket using trio.socket.from_stdlib_socket anyways (see here), so if I do decide to go this route, I've got a workaround.

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

No branches or pull requests

2 participants