You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
Load balancer points to an autoscaling group, routing to a single, constant port (eg 8000)
Assign a tag to the autoscaling group that defines the target number of processes
Propagate this tag to the instance
Load the tag from the AWS metadata service as part of a parent systemd task, determining how many processes to start
The parent systemd task starts X child tasks based on that
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.
Specifically, should there be a way to issue arbitrary
setsockopt
calls inopen_tcp_stream
andopen_tcp_listeners
, before the socket is bound by callingconnect
orbind
?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.
The text was updated successfully, but these errors were encountered: