From d85480a2986639b408b7c1f99e29b09e70950954 Mon Sep 17 00:00:00 2001 From: Eric Wong Date: Sat, 10 Oct 2009 00:21:23 -0700 Subject: DESIGN: address concerns about on-demand and thundering herd Based on a private email I just received. --- DESIGN | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'DESIGN') diff --git a/DESIGN b/DESIGN index badc473..1d195c7 100644 --- a/DESIGN +++ b/DESIGN @@ -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 -- cgit v1.2.3-24-ge0c7