191–200 of 437 posts
Good lord!!!!! Percentage of the requests served within a certain time (ms) 50% 844 66% 2977 75% 5032 80% 7575 90% 16052 95% 20069 98% 29282 99% 30029 100% 30029 (longest request) Those numbers are amazingly awful. If I ever run ab and see 4 digits I assume I need to optimize my software or server. But 5 digits? Why in the world would a company spend $20,000 a month for service this awful?
This kind of validates an idea I've been flirting with: a Heroku-like service which routes requests via AMQP or similar message broker and actually exposes the routing dynamics to the client apps. From a naive, inexperienced view the idea of having web nodes "pull" requests from a central queue rather than the queue taking uneducated guesses seems to be a no-brainer. I can see this making long-running requests (keep-…
Not exactly nodes pulling messages off a queue, but closer to something like that?
Earlier quoted context omitted.
no, at x level of concurrency most set ups wont spend 16 seconds or more on 10% of their requests.
You mean because they'll crash before then? Otherwise I don't follow. Surely there's always a limit to how many simultaneous requests can be processed at once.
How do they know what algorithm Heroku uses for randomization to stimulate the results? The differences in simulations are astonishing, I would not think Heroku's engineers were fine with this approach. 'Let's push this random balancing out.. 1000% increase in resources? Oh well, just update documentation!'
Earlier quoted context omitted.
On further thought, Heroku users could probably even approximate the benefits from the Mitzenmacher power-of-two-choices insight (mentioned elsewhere in thread), without Heroku's systemic help, by having dynos shed their own excess load. Assume each unicorn can tell how many of its workers are engaged. The 1st thing any worker does – before any other IO/DB/net-intensive work – would be to check if the dyno is 'loaded…
Most of the 'Power of two choices' I've read about assumes the presence of a global queue ( http://www.eecs.harvard.edu/~michaelm/postscripts/handbook20... ) -- there's a parallel variety, but they go light on details in that text. I'm unaware of how Heroku does things. I'd guess they dropped the global queue because it's unpractical (failure prone, not scalable as it's a single point of contention). I'm mostly surpr…
Question from a non-Ruby-expert: does Thin, which uses Event Machine, help with this at all, or do requests still block on other IO like database calls, etc?
You probably need an app that is built on like: https://github.com/raggi/async_sinatra
Earlier quoted context omitted.
The requests will not be served at the same time , that's the whole point. If a request is routed to a busy dyno, you will have to wait that the previous job finish before being able to start yours.
I believe the article is saying that this wait will only occur with Rails due to it being single threaded? Reactor pattern frameworks like node don't suffer the same issue.
This kind of validates an idea I've been flirting with: a Heroku-like service which routes requests via AMQP or similar message broker and actually exposes the routing dynamics to the client apps. From a naive, inexperienced view the idea of having web nodes "pull" requests from a central queue rather than the queue taking uneducated guesses seems to be a no-brainer. I can see this making long-running requests (keep-…
A possible solution for the proxy and the dynos to agree on a protocol where the proxy passes a request to the dyno and the latter can give up with a status code that says "retry with another dyno". This could go on to up to the 30s timeout limit that Heroku has now.
Earlier quoted context omitted.
This is not a new revelation. I got them to admit to it 2 years ago. http://tiwatson.com/blog/2011-2-17-heroku-no-longer-using-a-... and specifically: https://groups.google.com/forum/?fromgroups#!msg/heroku/8eOo...
But then again, those two links don't address the core of the problem: Heroku is used by tons of people around the world. Some of them are paying good money for the service. Given the amount of scrutiny under which they operate, what is the incentive for them to turn an algorithm into a less effective one and still charge the same amount of money in a growing "cloud economy" where companies providing the same kind of…
Meanwhile, AWS has been a dominant presence in the "Stupid Poor" market segment.
The other two quadrants do not exist.