Clifton King <[email protected]> wrote: > We experience the same problem. I believe the problem has more to do > with the kernel CPU scheduler than anything else. If you figure put a > reliable way to spread the load, I'd like to hear it.
Load not being spread is /not/ a problem unless there are requests that get stuck in the listen queue. If no requests are actually stuck in the queue (light load), the kernel is right to put requests into the most recently used worker since it can get better CPU cache behavior this way. == The real problem Under high loads (many cores, fast responses), Unicorn currently uses more resources because of non-blocking accept() + select(). This isn't a noticeable problem for most machines (1-16 cores). Future versions of Unicorn may take advantage of /blocking/ accept() optimizations under Linux. Rainbows! already lets you take advantage of this behavior if you meet the following requirements: * Ruby 1.9.x under Linux * only one listen socket (if worker_connections == 1 under Rainbows!) * use ThreadPool|XEpollThreadPool|XEpollThreadSpawn|XEpoll I haven't had a chance to benchmark any of this on very big machines so I have no idea how well it actually works compared to Unicorn, only how well it works in theory :) Blocking accept() under Ruby 1.9.x + Linux should distribute load evenly across workers in all situations, even in the non-busy cases where load distribution doesn't matter (your case :). [1] - http://rainbows.rubyforge.org/Rainbows/XEpollThreadPool.html -- Eric Wong _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
