# RE: Mongrel + RubyOnRails + FileUploads = Problems?

**URL:** <https://www.ruby-forum.com/t/re-mongrel-rubyonrails-fileuploads-problems/94451>\
**Category:** Rails\
**Created:** [May 3, 2006, 9:08pm UTC](https://www.ruby-forum.com/t/re-mongrel-rubyonrails-fileuploads-problems/94451 "2006-05-03T21:08:30Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![dacbo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b9e5f3/32.png) [@dacbo](https://www.ruby-forum.com/u/dacbo)\
**Post date:** [May 3, 2006, 9:08pm UTC](https://www.ruby-forum.com/t/re-mongrel-rubyonrails-fileuploads-problems/94451/1 "2006-05-03T21:08:30Z")

</div>

So I could run multiple mongrel instances on one server and use a proxy  
load balancer?

Chris

---

<div class="post-metadata">

**Author:** ![dacbo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b9e5f3/32.png) [@dacbo](https://www.ruby-forum.com/u/dacbo)\
**Post date:** [May 3, 2006, 10:32pm UTC](https://www.ruby-forum.com/t/re-mongrel-rubyonrails-fileuploads-problems/94451/2 "2006-05-03T22:32:13Z")

</div>

Yes.

–  
– Tom M.

---

<div class="post-metadata">

**Author:** ![dacbo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b9e5f3/32.png) [@dacbo](https://www.ruby-forum.com/u/dacbo)\
**Post date:** [May 3, 2006, 11:15pm UTC](https://www.ruby-forum.com/t/re-mongrel-rubyonrails-fileuploads-problems/94451/3 "2006-05-03T23:15:41Z")

</div>

Wait… this is kind of bad… if I understand this right…

1 dispatcher means that if someone uplaods a file, nobody else can use  
the  
site?

So 2 dispatchers works until two people upload a file at the same  
time… so  
really, this is not going to scale well at all if you’re trying to do  
something like flickr.

With that logic you’d need 100 dispatchers if you expected 100 users to  
be  
concurrently using your site to upload files.

YouTube gets 25,000 submissions per day… does that mean Rails could  
never  
be used to build a site like that?

I just can’t believe that’s the case.

---

<div class="post-metadata">

**Author:** ![dacbo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b9e5f3/32.png) [@dacbo](https://www.ruby-forum.com/u/dacbo)\
**Post date:** [May 4, 2006, 3:26am UTC](https://www.ruby-forum.com/t/re-mongrel-rubyonrails-fileuploads-problems/94451/4 "2006-05-04T03:26:37Z")

</div>

Hey Brian,

On 5/3/06 5:12 PM, “Brian H.” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Wait… this is kind of bad… if I understand this right…
> 
> 1 dispatcher means that if someone uplaods a file, nobody else can use the  
> site?

Yep, for the time it takes Rails to process the uploaded file with  
cgi.rb.  
If you’ve got an insane amount of upload content then 1 won’t work at  
all.

> So 2 dispatchers works until two people upload a file at the same time… so  
> really, this is not going to scale well at all if you’re trying to do  
> something like flickr.

Yep, then there’s a delay. But, the story is a bit more complex.

> With that logic you’d need 100 dispatchers if you expected 100 users to be  
> concurrently using your site to upload files.

100 concurrent users is an _insane_ number of actual people in the  
process  
queue. The thing to keep in mind is that you can’t measure users since  
that’s behavior dependent. You could have a site that users hit rarely,  
where 100 concurrent means you have billions of users. You could have a  
chat site like campfire where 100 concurrent could mean thousands. It  
all  
depends on user behavior.

The real way to figure out what kind of req/sec equates to a concurrency  
level is to use simulation. There’s math methods using queuing theory  
that  
work decent if you need to figure your require concurrency before you  
build  
the system. If you have the system built already then you need to write  
a  
simulator tool or use an existing one that will perform a simulation  
against  
your live site.

A key thing with this though is you can’t really use the results as a  
measurement of performance. It does tell you how well the site handles  
load, generally how fast that simulated process might be, and what kind  
of  
additional hardware you’d need. But, to really find out how to tune a  
particular part of the process you need to go back to performance  
measurements with a tool like httperf.

> YouTube gets 25,000 submissions per day… does that mean Rails could never  
> be used to build a site like that?

This is something else that’s kind of weird. I’m assuming most people  
here  
have a basic understanding of math but for some reason they throw out  
these  
kinds of measurements. Any “I get X per day” is really pretty useless  
since  
it doesn’t include a distribution. If you assume that this 25k is  
steady  
and average it out that’s like .29 req/second. No way that’s right  
since  
there’s probably some kind of statistical distribution for the requests.

The measurement would have to be augmented with a peak measurement over  
a  
smaller period of time. For example, “YouTube get 25k submissions/day  
with  
a peak of 1400/hour and .38/second.” Then you start to get a bigger  
picture.

Anyway, hope that clears some things up. The gist is that you can  
usually  
handle a lot more concurrent connections with lower numbers of backends  
then  
you think, but you need to run simulations to really determine this.

Zed A. Shaw

> **[Zed A. shaw](https://zedshaw.com/)**
>
> Personal essays and writings by Zed A. Shaw.

[http://mongrel.rubyforge.org/](http://mongrel.rubyforge.org/)
