3 ms·
This is still not ideal. Even if you're running unicorn, you're still susceptible to queueing spikes due to random load balancing. The concurrency just gives
by beambot 14y ago
This is still not ideal. Even if you're running unicorn, you're still susceptible to queueing spikes due to random load balancing. The concurrency just gives you a small buffer and/or some smoothing on 95th percentile responses. Right?
At least there's a commitment to update the reporting tools... getting bad data in New Relic was (IMHO) the worst -- even worse than out-of-date docs.
- bgentry 14y agoActually, no. Using unicorn with only 2 workers makes a tremendous difference, not just incremental. RapGenius' own statistical model demonstrates this. Picture each individual dyno in that case as its own "intelligent router". Since it's not distributed and this requires no network coordination, the job of knowing which workers are available becomes trivial. If you're inclined to read up on queuing theory, you'll see that having at least 2 processes per worker makes the problem much simpler.
- beambot 14y agoFantastic, that's good to hear. I'm able to run ~5 workers on Heroku with gunicorn (Django), so I imagine that means I'm outta the woods for a while at least. I would love to read up a bit on queuing theory. Any good pointers?
- shabble 14y agoThere's a basic interactive + theory overview at http://homepages.inf.ed.ac.uk/jeh/Simjava/queueing/mm1_q/mm1_q.html http://homepages.inf.ed.ac.uk/jeh/Simjava/queueing/mm1_q/mm1... (NB: via in-browser java applets, which most things have disabled by default just now)