russell muetzelfeldt <[email protected]> wrote: > I'm putting together a small web frontend for a client to upload files > into an existing application. It's trivial - there will never be more > than a (small) handful of concurrent connections, but I need a > streaming rack.input for upload progress on files up to 500MB or so. I > was planning on using Rainbows! with ThreadSpawn and > worker_connections=1, then noticed that unicorn is also listed as > having streaming rack.input.
:ThreadSpawn + worker_connections=1 and the (default) :Base option are almost the same in Rainbows! if you don't want to worry about your app being thread-safe at all. > While what I'm doing is pretty much the opposite of the unicorn design > case, is there any reason in this scenario for me to use Rainbows!, or > should I just go with unicorn and enough backends to handle a couple > of concurrent uploads and the minimal other frontend bits? Rainbows! can (and does by default) limit upload sizes (client_max_body_size) for handling untrusted clients who may try to run you out of space. Since performance/scalability isn't your concern, it depends on whether you trust your clients to not upload until you run out of disk space. -- 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
