4 ms·

Several Rails apps I develop have been suffering from similar issues. Perhaps 2-3% of requests take 0.4-2s in just processing. If the allocation is a little int

by 46Bit 14y ago

Several Rails apps I develop have been suffering from similar issues. Perhaps 2-3% of requests take 0.4-2s in just processing. If the allocation is a little intelligent, it'll not perform too badly and is less work than much harder optimization. Yet if it's random, it'll queue up horribly. I'm pissed. Spent way too much time unable to explain it to coworkers, thinking I just didn't understand Heroku's platform and that it was my fault. Turns out, I didn't understand it, because Heroku never thought to clearly mention something that's pretty important. Easiest fix: moving to EC2 next week. I've wanted to ever since our issues became evident but it's hard to make a good argument from handwaving about 'problems'.

jholman 14y ago
> Easiest fix: moving to EC2 next week. I've wanted to ever since these issues became evident but it's hard to make a good argument from handwaving about 'problems'. Of course, then you need to solve all these problems yourself. That sounds pretty easy, you'll have it done next week no problem! That was sarcastic, but this isn't: good luck, let us know how it goes.
- 46Bit 14y ago
  > Of course, then you need to solve all these problems yourself. That sounds pretty easy, you'll have it done next week no problem! I agree with this, actually. I know it's not simple to do your own servers when you're growing. Yet I'd rather improve my existing ops skills a bit than have to setup everything as async APIs (on EC2 anyway). That's the only way I can see that I can solve this.
  - timr 14y ago
    "Yet I'd rather improve my existing ops skills a bit than have to setup everything as async APIs (on EC2 anyway). That's the only way I can see that I can solve this." You're going to discover that a lot of "ops skills" boils down to "do things asynchronously whenever possible". And while nearly any smart engineer can think of the "right" way of doing something, finding the time to do it all is a huge opportunity cost. That's what the parent is trying to say. It's not that you can't do it; it's that it's a really bad idea to do it, at first.
    - coldtea 14y ago
      >That's what the parent is trying to say. It's not that you can't do it; it's that it's a really bad idea to do it, at first. This "bad idea" is how 90% of the web works...
- loopdoend 14y ago
  It's a lot easier than you think when you aren't limited by artificial restrictions on the number of concurrent requests you can serve. Taking out what could be considered here to be a hostile intermediary will free up tech resources to fix problems that actually exist. I can only imagine how these guys must have been beating their heads against the wall. Heroku charges a premium price and should be providing a premium service.
- codewright 14y ago
  I've done dev-ops in the ads industry before, it's really not that hard if you're a competent programmer. You just have to take a more studious approach than most non-dev-ops programmers and read up on things before deploying them. But if you want to let the various PAAS providers put the fear into you, that's your cowardice. Let the others learn as they may. Edit: To clarify, Heroku is making the problem harder on themselves than it would be for an individual to serve their own needs because of the complexity managing so many customers and apps. You don't have to be Heroku to do for yourself what they offer.
  - 46Bit 14y ago
    Thanks for this codewright. I've consistently found that learning things others are afraid of is a good business decision - and I reckon this is a big one.
- coldtea 14y ago
  >Of course, then you need to solve all these problems yourself. That sounds pretty easy, you'll have it done next week no problem! Depending on the complexity of their setup, they COULD have it done next week no problem. After all tens of thousands of other sites have. It's not like everybody except Google and Facebook is using Heroku.
- vidarh 14y ago
  Solving this problem is easy: Run haproxy, and he'll have detailed control over the balancing algorithm, including balancing by least connections and a number of other measures (if he, for example, wants to segregate the long running requests on a specific set of backends, it's trivial).

by 46Bit 14y ago

jholman 14y ago

> Easiest fix: moving to EC2 next week. I've wanted to ever since these issues became evident but it's hard to make a good argument from handwaving about 'problems'. Of course, then you need to solve all these problems yourself. That sounds pretty easy, you'll have it done next week no problem! That was sarcastic, but this isn't: good luck, let us know how it goes.

46Bit 14y ago
> Of course, then you need to solve all these problems yourself. That sounds pretty easy, you'll have it done next week no problem! I agree with this, actually. I know it's not simple to do your own servers when you're growing. Yet I'd rather improve my existing ops skills a bit than have to setup everything as async APIs (on EC2 anyway). That's the only way I can see that I can solve this.
- timr 14y ago
  "Yet I'd rather improve my existing ops skills a bit than have to setup everything as async APIs (on EC2 anyway). That's the only way I can see that I can solve this." You're going to discover that a lot of "ops skills" boils down to "do things asynchronously whenever possible". And while nearly any smart engineer can think of the "right" way of doing something, finding the time to do it all is a huge opportunity cost. That's what the parent is trying to say. It's not that you can't do it; it's that it's a really bad idea to do it, at first.
  - coldtea 14y ago
    >That's what the parent is trying to say. It's not that you can't do it; it's that it's a really bad idea to do it, at first. This "bad idea" is how 90% of the web works...
loopdoend 14y ago
It's a lot easier than you think when you aren't limited by artificial restrictions on the number of concurrent requests you can serve. Taking out what could be considered here to be a hostile intermediary will free up tech resources to fix problems that actually exist. I can only imagine how these guys must have been beating their heads against the wall. Heroku charges a premium price and should be providing a premium service.
codewright 14y ago
I've done dev-ops in the ads industry before, it's really not that hard if you're a competent programmer. You just have to take a more studious approach than most non-dev-ops programmers and read up on things before deploying them. But if you want to let the various PAAS providers put the fear into you, that's your cowardice. Let the others learn as they may. Edit: To clarify, Heroku is making the problem harder on themselves than it would be for an individual to serve their own needs because of the complexity managing so many customers and apps. You don't have to be Heroku to do for yourself what they offer.
- 46Bit 14y ago
  Thanks for this codewright. I've consistently found that learning things others are afraid of is a good business decision - and I reckon this is a big one.
coldtea 14y ago
>Of course, then you need to solve all these problems yourself. That sounds pretty easy, you'll have it done next week no problem! Depending on the complexity of their setup, they COULD have it done next week no problem. After all tens of thousands of other sites have. It's not like everybody except Google and Facebook is using Heroku.
vidarh 14y ago
Solving this problem is easy: Run haproxy, and he'll have detailed control over the balancing algorithm, including balancing by least connections and a number of other measures (if he, for example, wants to segregate the long running requests on a specific set of backends, it's trivial).