Mongrel - good enough?


#1

I want to deploy RoR site’s (Intranet) for small offices/businesses that
will get light traffic (estimating at max about 40 hits per minute at
peak times). Lots of AJAX going on more than anything (update checks to
the DB - Postgresql). I’d rather not use Lighttd, Apache, etc. as I
want to have a streamlined install that is very easy for the end users.
The catch is I expect large uploads/downloads (10,20,etc. meg in size)
of documents (5-10 uploads per day, 70 or so downloads per day).

So this begs the question: Is Mongrel going to be able to handle this?
Anyone have any experience working with Mongrel?


#2

Roy Jenkins wrote:

I want to deploy RoR site’s (Intranet) for small offices/businesses that
will get light traffic (estimating at max about 40 hits per minute at
peak times). Lots of AJAX going on more than anything (update checks to
the DB - Postgresql). I’d rather not use Lighttd, Apache, etc. as I
want to have a streamlined install that is very easy for the end users.
The catch is I expect large uploads/downloads (10,20,etc. meg in size)
of documents (5-10 uploads per day, 70 or so downloads per day).

So this begs the question: Is Mongrel going to be able to handle this?
Anyone have any experience working with Mongrel?

Pure Ruby is probably going to be able to handle this. Although, if you
put
mongrel on a 486 with 16 MB of Ram you might get in trouble :wink:

-Sascha E.


#3

Sascha E. wrote:

Pure Ruby is probably going to be able to handle this. Although, if you
put
mongrel on a 486 with 16 MB of Ram you might get in trouble :wink:

Ideally I’d like to setup for the client the app on a Linode or
Rimuhosting Fedora system and at least around 80+ meg of dedicated ram,
running Postgresql, but also capable of SQLite for the smaller offices
that don’t need the horsepower. I know that some clients will want to
run this locally on their intranet, and that I don’t have a lot of
control over where they deploy it. I had one client who ran one of my
web apps on a local workstation actively used by an employee and it
hosted not only the web app but also Apache and MySQL. Everyone in the
office (15 or so people) connects to it throughout the day. It actually
worked pretty good, now however its deployed to a real web server.


#4

On Fri, 2006-06-09 at 23:24 +0200, Roy Jenkins wrote:

control over where they deploy it. I had one client who ran one of my
web apps on a local workstation actively used by an employee and it
hosted not only the web app but also Apache and MySQL. Everyone in the
office (15 or so people) connects to it throughout the day. It actually
worked pretty good, now however its deployed to a real web server.

Mongrel can do this with some caveats:

  • Use the pre-release, it’s got much better giant file handling. Use
    gem install mongrel --source=http://mongrel.rubyforge.org/releases/
  • More ram. Postgres and Mongrel itself will take up more than 80.
  • Don’t use Windows. Too much pain to support. If you’re letting
    folks install at the intranet then design a fixed non-win32 platform and
    your own rubygems repo for them to install from. Look at Mongrel
    Rakefile to see how to generate a gem source for people to download.
  • Consider using mongrel_cluster combined with virtual hosts to
    accomplish the same thing. You’d be surprised how many little virtual
    sites a well done single rails application with a reasonable pool of
    Mongrel handlers can support.
  • SQLite will bomb with more than one Mongrel process accessing the
    same database file with both 2 and 3 versions of sqlite. Use sqlite if
    the install is tiny and one Mongrel server can handle it.

Good luck.


Zed A. Shaw


http://mongrel.rubyforge.org/


#5

On Mon, 2006-06-12 at 22:16 +0200, Roy Jenkins wrote:

use
the clustering without much fuss at all, plus wrap this into a gem
and
forget about it.

Thanks for the info.

Yep, that’ll work, but you can’t do that with sqlite. If you’re looking
for no-fuss installs then it’s either sqlite or kirby base. I have no
idea if kirby base can handle multiple processes accessing the database.


Zed A. Shaw


http://mongrel.rubyforge.org/


#6

Zed S. wrote:

  • Use the pre-release, it’s got much better giant file handling. Use
    gem install mongrel --source=http://mongrel.rubyforge.org/releases/
  • More ram. Postgres and Mongrel itself will take up more than 80.
  • Don’t use Windows. Too much pain to support. If you’re letting
    folks install at the intranet then design a fixed non-win32 platform and
    your own rubygems repo for them to install from. Look at Mongrel
    Rakefile to see how to generate a gem source for people to download.
  • Consider using mongrel_cluster combined with virtual hosts to
    accomplish the same thing. You’d be surprised how many little virtual
    sites a well done single rails application with a reasonable pool of
    Mongrel handlers can support.
  • SQLite will bomb with more than one Mongrel process accessing the
    same database file with both 2 and 3 versions of sqlite. Use sqlite if
    the install is tiny and one Mongrel server can handle it.

Excellent advice Zed, thanks. More ram huh? I can probably knock the
virtual system up to 128 meg, I assume that would be enough? I’ve been
looking at Pound and it looks like I can plug that in front and just use
the clustering without much fuss at all, plus wrap this into a gem and
forget about it.

Thanks for the info.