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. 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? cheers Russell ----- Russell Muetzelfeldt <russm at slofith.org> Mundus vult decipi, ergo decipiatur.
russell muetzelfeldt <russm-rubyforge at slofith.org> 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
On 16/09/2011, at 9:11 PM, Eric Wong wrote:> :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.my reason for intending to run worker_connections=1 isn''t avoiding threading issues, but to allow app reloads without leaving around old instances of the app in server processes that are handling a 2+ hour upload. I passed on Rainbows::Base just because of the "not intended for production use" comment in the docs.> 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.ah, that''s a good point. I''ll be fronting through Pound for SSL, but having the server process limit upload size would be worthwhile.> 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.I trust them to not do that on purpose, but that doesn''t mean a lot. :/ cheers Russell ----- Russell Muetzelfeldt <russm at slofith.org> Mundus vult decipi, ergo decipiatur.
russell muetzelfeldt <russm-rubyforge at slofith.org> wrote:> On 16/09/2011, at 9:11 PM, Eric Wong wrote: > > :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.<snip>> I passed on Rainbows::Base just because of the "not intended > for production use" comment in the docs.Ah, Base and worker_connections=1 (anywhere) is risky for dealing with untrusted clients directly.