4 ms·
I'm not able to follow parts of the post. Our routing cluster remained small for most of Bamboo’s history, which masked this inefficiency. If you went from 1
by jeswin 14y ago
I'm not able to follow parts of the post.
Our routing cluster remained small for most of Bamboo’s history, which masked this inefficiency.
If you went from 1 router to 2, 50% of routers can't optimally route a request. If you went from 2 to 3, you would have 66% which can't route. 3 to 4, 75%.
Once you get to say 10 routers, you are already at 90% sub-optimal routing. So are they saying, the had only 1 or 2 routers earlier?
- gojomo 14y agoI think that is what they're saying: for a long time Bamboo only had very few routers. One simple HTTP router can move a lot of requests! (Maybe other topologies also hid the problem for a while, such as apps having traffic that still tended to come through one router even though coming from any was possible.)
- cpleppert 14y agoThis is exactly what I was thinking as I was reading this blog post. I did a double take when I read that because it makes absolutely no sense at all. It seems to imply that their fabled web serving stack never actually worked as advertised but no one cared or complained publicly enough to make Heroku explain the issue. I just can't believe that Heroku had like 2-5 routers in their entire stack. I'm wondering if maybe they have some kind of simple sharding for routers based on the app name so all hash values go to a small set of routers. I can understand if that was the case how large numbers of small applications would seem to developers and heroku customer support to be using a per application queue. Of course, this would break down the instant there were very large applications served on heroku that would overwhelm the small number of routers assigned to each shard bucket.