diff options
author | Eric Wong <normalperson@yhbt.net> | 2009-10-10 00:21:23 -0700 |
---|---|---|
committer | Eric Wong <normalperson@yhbt.net> | 2009-10-10 00:24:47 -0700 |
commit | d85480a2986639b408b7c1f99e29b09e70950954 (patch) | |
tree | b3bd80e6fbb7d59fa49cb1f6afdaa117803811f1 | |
parent | 79f0b94b946d154fed14b8cbc99430d1a417cb49 (diff) | |
download | unicorn-d85480a2986639b408b7c1f99e29b09e70950954.tar.gz |
Based on a private email I just received.
-rw-r--r-- | DESIGN | 16 |
1 files changed, 16 insertions, 0 deletions
@@ -55,6 +55,22 @@ applications that are running all the time since worker processes will only select()/accept() outside of the application dispatch. +* Additionally, thundering herds are much smaller than with + configurations using existing prefork servers. Process counts should + only be scaled to backend resources, _never_ to the number of expected + clients like is typical with blocking prefork servers. So while we've + seen instances of popular prefork servers configured to run many + hundreds of worker processes, Unicorn deployments are typically only + 2-4 processes per-core. + +* On-demand scaling of worker processes never happens automatically. + Again, Unicorn is concerned about scaling to backend limits and should + never configured in a fashion where it could be waiting on slow + clients. For extremely rare circumstances, we provide TTIN and TTOU + signal handlers to increment/decrement your process counts without + reloading. Think of it as driving a car with manual transmission: + you have a lot more control if you know what you're doing. + * Blocking I/O is used for clients. This allows a simpler code path to be followed within the Ruby interpreter and fewer syscalls. Applications that use threads continue to work if Unicorn |