search

getlantern / browsersunbounded

Interoperable browser-based P2P proxies for censorship circumvention
GNU General Public License v3.0
11 stars 0 forks source link

Overcome scale limitations for launch #120

Closed noahlevenson closed 1 year ago

noahlevenson commented 1 year ago

Google Cloud Run imposes some surprisingly aggressive limits on the number of concurrent connections allowed. It's discussed here: https://github.com/getlantern/broflake/issues/74

I originally thought that these limits would pose no problems for launch, but I've changed my mind. By bumping the widget concurrency to 10 and launching with an extension, we're creating way more persistent connections than I anticipated.

Must fix for launch. There's two general approaches:

  1. Reduce the number of connections (by switching to an HTTP/2 client which muxes requests) and muxing QUIC over fewer WebSockets. (Open question: Does GCR consider a single HTTP/2 connection with > 1 muxed requests to be a single connection, or multiple connections? If it's the latter, this approach is unviable.)

  2. Scale the backend services. Easier said than done, for reasons of container affinity and shared state and such.

Here's what I think will work:

The egress server will theoretically autoscale without issue, because GCR claims to enforce affinity for WebSocket connections. So we should just increase the max containers and do some testing.

Freddie will not autoscale, because multiple instances of Freddie do not share state with one another. So -- assuming HTTP/2 request muxing is a viable way to reduce server load from the perspective of GCR -- and assuming HTTP/2 is kosher for domain fronting -- we should try to get clients muxing requests.

noahlevenson commented 1 year ago

Closing because we will launch on Heroku instead of GCR...