4 ms·

Great question! We're aware of the Heroku issues, and they don't fully apply in our case. We currently do not have any queues in the router other than the kerne

Great question! We're aware of the Heroku issues, and they don't fully apply in our case. We currently do not have any queues in the router other than the kernel's accept queue. All incoming connections are assigned a goroutine immediately and the requests are proxied back to service instances without queuing. So if your application instances can handle concurrent requests, the performance impact of random load balancing should not be huge. We are absolutely open to implementing other balancing algorithms, including least connections. The one caveat is that at any time multiple routers will be in operation and we're not going to do extensive coordination between them, so the balancing will never be perfect.

mikejarema 11y ago
Got it, makes complete sense. Thanks for the direct answer. A bit more info on the app I'm thinking of testing with Flynn: each instance has a single dedicated resource (actually a psuedo terminal sitting on top of a command line tool). Any given instance is incapable of handling requests concurrently, they queue up at the instance. So the app's concurrency model relies on smart load balancing at the router itself. I've got HAProxy playing this role, but have done a bit of a hack job juggling the containers which implement the various microservices. I'll give Flynn a go to see if the simplicity it gives me in managing my deployment is worth the routing tradeoff for now, but I would definitely love to see Flynn's router adapted as you describe.