Forum: Ruby on Rails Mongrel - good enough?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Roy Jenkins (Guest)
on 2006-06-10 01:02
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?
Sascha E. (Guest)
on 2006-06-10 01:13
(Received via mailing list)
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 ;)

-Sascha E.
Roy Jenkins (Guest)
on 2006-06-10 01:24
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 ;)

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.
Zed S. (Guest)
on 2006-06-10 02:14
(Received via mailing list)
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://www.zedshaw.com/
http://mongrel.rubyforge.org/
Roy Jenkins (Guest)
on 2006-06-13 00:16
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.
Zed S. (Guest)
on 2006-06-13 02:22
(Received via mailing list)
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://www.zedshaw.com/
http://mongrel.rubyforge.org/
This topic is locked and can not be replied to.