diff options
Diffstat (limited to 'DESIGN')
| -rw-r--r-- | DESIGN | 22 |
1 files changed, 19 insertions, 3 deletions
@@ -7,12 +7,12 @@ all clients down, just one. Only UNIX-like systems supporting fork() and file descriptor inheritance are supported. -* The Ragel->C HTTP parser is taken from Mongrel. This is the +* The Ragel+C HTTP parser is taken from Mongrel. This is the only non-Ruby part and there are no plans to add any more non-Ruby components. -* All HTTP protocol parsing and I/O is done just like Mongrel: - 1. read/parse HTTP request in full +* All HTTP protocol parsing and I/O is done much like Mongrel: + 1. read/parse HTTP request headers in full 2. call Rack application 3. write HTTP response back to the client @@ -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 |