5 ms·

Keep in mind with more Unicorn workers per box you will need fewer dynos overall so it does not necessarily mean you will have to pay double in the long run. At

Keep in mind with more Unicorn workers per box you will need fewer dynos overall so it does not necessarily mean you will have to pay double in the long run. At 1x Dynos we could only have 2 workers going but at 2x we could squeeze five workers in so we use half of the dynos we did before.

cygwin98 14y ago
Not so fast though. This might just be a quick fix. Any high-traffic sites might still see the same results as the routing alg is still random. Probably the guy who wrote the routing alg simulation can re-run his tests to see what kind of improvements this 2X can make.
- dkuebric 14y ago
  Yeah, I had the same thought when the discussion came around last time. I actually took the source to the simulations (thanks for sharing, rapgenius!) and did some experiments on how random routing performs if it's routing to backends that can handle various #s of concurrent requests. Here's the writeup: https://www.appneta.com/2013/02/21/the-taming-of-the-queue-measuring-the-impact-of-request-queueing/ https://www.appneta.com/2013/02/21/the-taming-of-the-queue-m... (Spoilers: turns out it gets a lot better very quickly.)
  - thu 14y ago
    Thanks for the writeup. It seems Heroku could implement easily a two-layer routing mesh to accomplish what you describe thought.
    - jcampbell1 14y ago
      I think that is the wrong conclusion. You still have the problem of having to design a system where the dynos communicate their queues to the second layer of the routing mesh. The solution is to have dynos large enough that you can run 8+ workers and let the operating system do all the complex scheduling.
      - thu 14y ago
        > and let the operating system do all the complex scheduling. So Heroku could spawn workers with a $FD environment variable instead of $PORT and the "complex scheduling" done by the OS _is_ the second routing layer. But really, they could still do a second level routing even outside a single OS as the scale of the distribution is much smaller, so having the routing mesh be aware of the worker availability seems feasible again.
jcampbell1 14y ago
It should save you even more than you describe, as you shouldn't need to over provision as much. The odds of two 95% percentile requests stalling your 1x dyno is pretty good. The odds of getting 5 such requests is much lower.
tolas 14y ago
Same here. We were struggling to fit 2 unicorn workers on a 1x dyno but can easily get 4 on a 2x. We're paying the same amount for twice the concurrency. The 2x dynos with unicorn have pretty much solved the queuing issues for us.
- rickyc091 14y ago
  Wait up... I'm a bit confused here. How is it that you were struggling with 2 unicorns on a 1x (512mb) dyno, but 4 unicorns works on a 2x (1024mb) dyno?
  - jordanthoms 14y ago
    Unicorn instances fork after loading rails, so they share memory. (This will work better on ruby 2.0 with the copy on write friendly GC)
FooBarWidget 14y ago
Unfortunately it would appear Unicorn on Heroku may not be a good choice, because apparently Heroku doesn't buffer request bodies properly. http://rubyforge.org/pipermail/mongrel-unicorn/2013-April/001743.html http://rubyforge.org/pipermail/mongrel-unicorn/2013-April/00...
- jcampbell1 14y ago
  Wow, that sounds really bad. If I understand the message, it seems like you take a heroku/unicorn site offline with something as simple as: ab -n 100 -c 100 -p big_file.mov http://site.com/ They should treat this like a zero-day.

cygwin98 14y ago

Not so fast though. This might just be a quick fix. Any high-traffic sites might still see the same results as the routing alg is still random. Probably the guy who wrote the routing alg simulation can re-run his tests to see what kind of improvements this 2X can make.

dkuebric 14y ago
Yeah, I had the same thought when the discussion came around last time. I actually took the source to the simulations (thanks for sharing, rapgenius!) and did some experiments on how random routing performs if it's routing to backends that can handle various #s of concurrent requests. Here's the writeup: https://www.appneta.com/2013/02/21/the-taming-of-the-queue-measuring-the-impact-of-request-queueing/ https://www.appneta.com/2013/02/21/the-taming-of-the-queue-m... (Spoilers: turns out it gets a lot better very quickly.)
- thu 14y ago
  Thanks for the writeup. It seems Heroku could implement easily a two-layer routing mesh to accomplish what you describe thought.
  - jcampbell1 14y ago
    I think that is the wrong conclusion. You still have the problem of having to design a system where the dynos communicate their queues to the second layer of the routing mesh. The solution is to have dynos large enough that you can run 8+ workers and let the operating system do all the complex scheduling.
    - thu 14y ago
      > and let the operating system do all the complex scheduling. So Heroku could spawn workers with a $FD environment variable instead of $PORT and the "complex scheduling" done by the OS _is_ the second routing layer. But really, they could still do a second level routing even outside a single OS as the scale of the distribution is much smaller, so having the routing mesh be aware of the worker availability seems feasible again.

jcampbell1 14y ago

It should save you even more than you describe, as you shouldn't need to over provision as much. The odds of two 95% percentile requests stalling your 1x dyno is pretty good. The odds of getting 5 such requests is much lower.

tolas 14y ago

Same here. We were struggling to fit 2 unicorn workers on a 1x dyno but can easily get 4 on a 2x. We're paying the same amount for twice the concurrency. The 2x dynos with unicorn have pretty much solved the queuing issues for us.

rickyc091 14y ago
Wait up... I'm a bit confused here. How is it that you were struggling with 2 unicorns on a 1x (512mb) dyno, but 4 unicorns works on a 2x (1024mb) dyno?
- jordanthoms 14y ago
  Unicorn instances fork after loading rails, so they share memory. (This will work better on ruby 2.0 with the copy on write friendly GC)

FooBarWidget 14y ago

Unfortunately it would appear Unicorn on Heroku may not be a good choice, because apparently Heroku doesn't buffer request bodies properly. http://rubyforge.org/pipermail/mongrel-unicorn/2013-April/001743.html http://rubyforge.org/pipermail/mongrel-unicorn/2013-April/00...

jcampbell1 14y ago
Wow, that sounds really bad. If I understand the message, it seems like you take a heroku/unicorn site offline with something as simple as: ab -n 100 -c 100 -p big_file.mov http://site.com/ They should treat this like a zero-day.