Rails - Jul 2006 - When is a site too small for Rails?

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 :)

	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 :)

-Brent

On 7/18/06, Brent Dillingham <brent@simplesis.com>
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

On Tuesday 18 July 2006 18:56, Brent Dillingham 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060718/d8bc679b/attachment.bin

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 Kohn <mailto:dan@dankohn.com>
<http://www.dankohn.com/>  <tel:+1-415-233-1000>



On Jul 18, 2006, at 11:56 AM, Brent Dillingham wrote:
> 	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 :)
>
> 	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 :)
>
> -Brent
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

> 	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 :)
> 	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 :)  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 :)

-philip

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.

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


Brent Dillingham 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

-- 
Posted via http://www.ruby-forum.com/.