When is a site too small for Rails?

Rails
1

Hey, folks.

Mainly, I'm looking for some guidance here.  A couple months ago the

buzz around Rails become too much for me, and I finally decided to
give in and learn the framework. This was all very new to me – most
of my focus in the past couple years has been solely in design with
static XHTML + CSS. I dabbled in PHP, but nothing significant.
Well, I love Rails, and it opened me up to Ruby, as well as other
scripting languages. Getting it all up and running on my development
machine (my laptop) as well as a newly acquired VPS for production
has also been a blast, and a tremendous learning experience. I knew
next to nothing about UNIX prior to this, other than that OS X runs
on top of it :slight_smile:

Anyway, to my question: when is a site too small for Rails?  I'm

really interested in doing web development for a living, and trying
very hard to be self-taught at it. I do have a day job right now, so
the freelance projects I’ve picked up so far (only one of them is
actually in production right now) have been for pretty small sites
that, I think, could easily be made into static HTML plus something
in the backend for administrivia. But should they be? The site I
have in production right now is for a local restaurant, and I made it
in Rails. It has just three sections, plus an admin backend for some
basic CMS functionality. If you’d like to get a feel for the site,
see it at http://wasabifusion.com. Developing the site with Rails was
seriously easy, and a lot of fun. The CMS functionality was simple,
and I was able to spruce it up quite a bit with some conservative use
of the scriptaculous AJAX helpers.

But here's my problem ... deployment has been not-so-simple.

Originally I deployed it on Dreamhost, and have had issues with
that. One major issue I’ve encountered is that my dispatch.fcgi
processes seem to like to multiply in the night. Usually they
multiply to around five, and at 25megs or so each, that’s a lot of
RAM! I’m a nice guy. I don’t want to do that to the rest of the
people on my Dreamhost server. I’ve come to the conclusion that they
multiply because eventually they’ll get stored into swap, and then a
request comes along for the website, but before the process can be
resurrected into real memory, the request times out and another
process is spawned. This may be wrong, but it’s annoying regardless,
and what it means for my visitors is that they’ll have to wait for
the whole framework to load again if they visit a few hours after
anyone else.

Before I considered how much RAM each fastcgi (or Mongrel, for that

matter) process would take up, I thought that a VPS would be the
solution to this. I was quite wrong. I have a VPS now with 160MB of
RAM at rimuhosting.com, which runs me $30 a month. Say that I do
quite well in my freelance business, and I get up to hosting more and
more sites. Eventually I’m going to bust that amount of RAM (and the
maybe the bandwidth allocation, too, as it’s puny compared to
Dreamhost’s)… so it would seem that a VPS isn’t going to be viable
if I want to do ALL of my sites in Rails.

I've decided that I've been shortsighted in thinking I can do all of

my sites in Rails. The restaurant site, right now, probably only
gets 10 unqiue visitors a day. Some of you may laugh when you hear
that I chose Rails to do a site like with that low amount of traffic,
but I simply didn’t know any better at the time. So my question you
then, smartypants, what should I have done? I like how simple the
CMS backend was to create with Rails. I want to be able to offer
that to all of my clients. I’ve invested a lot of time into Rails,
so I hate to leave it and learn something like PHP to write all my
small sites from scratch. Maybe there’s another PHP/Python/Ruby/
whatever framework out there I can use? Maybe I can use Rails simply
for the backend and have it generate everything staticly on each change?

I'm open for any advice at all.  Sorry for the long introduction,

but I felt it might help :slight_smile:

-Brent

2

On 7/18/06, Brent D. [email protected] wrote:

basic CMS functionality. If you’d like to get a feel for the site,
see it at http://wasabifusion.com.

That site looks nice, but did they really want their prices to have 1
decimal place?

I’ve decided that I’ve been shortsighted in thinking I can do all of
my sites in Rails. The restaurant site, right now, probably only
gets 10 unqiue visitors a day. Some of you may laugh when you hear
that I chose Rails to do a site like with that low amount of traffic,
but I simply didn’t know any better at the time. So my question you
then, smartypants, what should I have done? I like how simple the
CMS backend was to create with Rails.

It’s more a matter of features than size. Do you really want to train
for and/or deal with updating content? Giving the client an admin
section to change basic data is a very nice plus. Who cares if it
only gets 10 hits per day, as long as the customer is happy with it?

Rails deployment is in a pretty large state of flux right now, and
mongrel is looking like it’s going to emerge as the winner. I think
you can expect to see the hosting and deployment aspects of Rails get
better and better.

– James

3

On Tuesday 18 July 2006 18:56, Brent D. wrote:

that. One major issue I’ve encountered is that my dispatch.fcgi
processes seem to like to multiply in the night. Usually they
multiply to around five, and at 25megs or so each, that’s a lot of
RAM! I’m a nice guy. I don’t want to do that to the rest of the
people on my Dreamhost server. I’ve come to the conclusion that they
multiply because eventually they’ll get stored into swap, and then a
request comes along for the website, but before the process can be
resurrected into real memory, the request times out and another
process is spawned.

If that’s the case, that means the server is horribly loaded and you
should switch hosting providers. Restoring ~25M from swap should take
less than 2 seconds on a “kind of busy” server.

My guess is that during the night the site is visited by googlebot et
al,
with a couple of requests in parallel, tricking the server into thinking
that there’s a “real” spike in demand and causing it to allocate more
processes.

then, smartypants, what should I have done? I like how simple the
CMS backend was to create with Rails. I want to be able to offer
that to all of my clients. I’ve invested a lot of time into Rails,

If you like rails, stick with it. If you want to conserve memory on
low-traffic sites, look into your webserver configuration and reduce the
maximum number of spawned fcgi processes.

4

First, don’t be hard on yourself for learning Rails. Remember that
the scarcest resource in any project is programmer’s time, not RAM on
a server. If Rails makes you efficient (and was fun to learn) then
it was a good choice.

I certainly understand the advantage of a shared hosting account like
Dreamhost for a few bucks a month that can serve dozens of domains.
If your main problem is that long running processes eat up too much
RAM, then I would seriously consider treating the symptoms rather
than switching to a VPS or, heaven forbid, PHP.

For example, have you considered just using a cron job to run the
capistrano reaper every couple hours. This task lets each FastCGI
process finish any outstanding requests and then die.

From : /usr/local/lib/ruby/gems/1.8/gems/capistrano-1.1.0/lib/
capistrano/recipes/standard.rb:

desc <<-DESC
Restart the FCGI processes on the app server. This uses the :use_sudo
variable to determine whether to use sudo or not. By
default, :use_sudo is
set to true, but you can set it to false if you are in a shared
environment.
DESC
task :restart, :roles => :app do
send(run_method, “#{current_path}/script/process/reaper”)
end

Or, here’s another cron option to keep your fcgi processes from
getting swapped out:

http://lists.rubyonrails.org/pipermail/rails/2006-January/010860.html

        - dan

–
Dan K. mailto:[email protected]
http://www.dankohn.com/ tel:+1-415-233-1000

5

Anyway, to my question: when is a site too small for Rails? I’m

When it’s too small to have a database. Or too big to be edited by
hand.
I don’t really think your issues are Rails specific. They apply to PHP
and Java and every other development “environment” out there.

You have some Rails specific issues, but that’s only because rails
hosting
is fairly new and by it’s nature eats a little more ram so isn’t as
“mass
hosting” friendly as say PHP. Although you could argue that point since
PHP could use just as much ram, it’s just not persistent so if no one
hits
your site it never gets activated. And right there we just learned how
web hosts make money :slight_smile:

Before I considered how much RAM each fastcgi (or Mongrel, for that
matter) process would take up, I thought that a VPS would be the solution to
this. I was quite wrong. I have a VPS now with 160MB of RAM at
rimuhosting.com, which runs me $30 a month. Say that I do quite well in my
freelance business, and I get up to hosting more and more sites. Eventually
I’m going to bust that amount of RAM (and the maybe the bandwidth allocation,
too, as it’s puny compared to Dreamhost’s)… so it would seem that a VPS
isn’t going to be viable if I want to do ALL of my sites in Rails.

If you’re doing well, you can afford to spend more on hosting. For
example, at layeredtech.com (among others, just happens I have a box
there) I pay $90 for 1gb, 100gb transfer (that’s in + out).

Let’s say I have one popular app. Even with only one mongrel instance
(and say it’s a lot of classes so maybe is 75mb) I can serve about 15
r/s
at least right? That’s a bit over 1 million rails pages per day
assuming they spread themselves out nicely :slight_smile: By the time you’re doing
that much traffic you’re going to have upgraded your servers to support
all the images/css/jss/flash you’re sending down as well.

Also, if you make use of page caching and I’m guessing you can since you
say it’s a “simple cms” and I’m guessing that means they don’t change it
that often, requests will never make it to mongrel at all allowing you
to
serve even more traffic.

I’ve decided that I’ve been shortsighted in thinking I can do all of
my sites in Rails. The restaurant site, right now, probably only gets 10
unqiue visitors a day. Some of you may laugh when you hear that I chose
Rails to do a site like with that low amount of traffic, but I simply didn’t
know any better at the time. So my question you then, smartypants, what
should I have done?

I don’t think you’ve been shortsighted in picking Rails. I think the
only
problem you have is thinking you can host every site you build on a
$30/mo
package. That just won’t work. But if you’re sites are successful it
shouldn’t be a problem.

That all said, back when I did web development, I was amazed how many
companies would spend $30K for a site, then complain about spending
$50-$100 for decent hosting. Never made much sense to me, but it
happened
a lot.

I like how simple the CMS backend was to create with
Rails. I want to be able to offer that to all of my clients. I’ve invested
a lot of time into Rails, so I hate to leave it and learn something like PHP
to write all my small sites from scratch. Maybe there’s another
PHP/Python/Ruby/whatever framework out there I can use? Maybe I can use
Rails simply for the backend and have it generate everything staticly on each
change?

I’d say stick with rails. And look into page (and fragment) caching.
And
get a dedicated box with a decent amount of ram (or make each customer
get
their own) and don’t worry about it :slight_smile:

-philip

6

People have given you some good advice. I’d like to chime in on a point
or two.

Brent D. wrote:

…If you’d like to get a feel for the site,
see it at http://wasabifusion.com.

Not such a big thing, but you might want to use number_to_currency in
your views to get two decimal places.

Originally I deployed it on Dreamhost, and have had issues with
that. One major issue I’ve encountered is that my dispatch.fcgi
processes seem to like to multiply in the night. Usually they
multiply to around five, and at 25megs or so each, that’s a lot of
RAM!

Dreamhost is somewhat of a hassle. But the dispatch.fcgi processes don’t
actually take 25 megs each. That’s their virtual size. A lot of that
memory is shared. For example, right now on my local machine I’m seeing
script/server at 27 megs and /path/to/app dispatch.fcgi at 27 megs. But
these are, for the most part, the same 27 megs. A good chunk of the 15
megs irb claims to have is included in that, too.

I’ve come to the conclusion that they
multiply because eventually they’ll get stored into swap, and then a
request comes along for the website, but before the process can be
resurrected into real memory, the request times out and another
process is spawned.

Somebody else said this doesn’t happen, but I think it’s close. I find
that if I send a request every ten minutes from a little script to each
of my DreamHost Rails sites, they work a lot better. The script also
tells me when DreamHost is completely hosed, as it is occasionally.

I’m open for any advice at all.

Buy low, sell high:-)

Are you using page caching in the restaurant site? If not, you should
be.

–Al Evans

7

Honestly, I would have done that site with static html/javascript and
a small cgi script for the form. If you need dynamic content, then
use something like rails. But if you don’t really need it, don’t use
it.