Re:Running Rails on Heroku Update
by aphyr on Sunday March 17, 2013 @03:51PM
(#5390707)
For single-threaded servers, request latency dominates--it's hard to get useful state information out of a dyno, because as soon as it's returned a response, its state has changed. You can add a dedicated stats endpoint to each server, but that requires cooperation from the customer's application. There are... alternate approaches, however.
[ Parent
| on HN ]
IMO, adding feedback mechanisms (e.g. LB polling app or server agent) are among the best ways to create smart, fast LBs without keeping a lot of expensive state. Calculating busyness is another question entirely but it's also a much easier problem to solve than stateful routers.
I'm not talking about polling. Presumably the server's response packets flow back through the webserver, unless they are doing DSR. You can piggyback data on that channel in a way that's transparent to the customer.