# When is a site too small for Rails? **URL:** \ **Category:** Rails\ **Created:** [July 18, 2006, 8:58pm UTC](https://www.ruby-forum.com/t/when-is-a-site-too-small-for-rails/98888 "2006-07-18T20:58:50Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Brent\_D](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/b9bd4f/32.png) [@Brent\_D](https://www.ruby-forum.com/u/Brent_D)\ **Post date:** [July 18, 2006, 8:58pm UTC](https://www.ruby-forum.com/t/when-is-a-site-too-small-for-rails/98888/1 "2006-07-18T20:58:50Z")
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](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](http://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 ---
**Author:** ![Brent\_D](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/b9bd4f/32.png) [@Brent\_D](https://www.ruby-forum.com/u/Brent_D)\ **Post date:** [July 18, 2006, 9:13pm UTC](https://www.ruby-forum.com/t/when-is-a-site-too-small-for-rails/98888/2 "2006-07-18T21:13:35Z")
On 7/18/06, Brent D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > basic CMS functionality. If you’d like to get a feel for the site, > see it at [http://wasabifusion.com](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 ---
**Author:** ![Brent\_D](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/b9bd4f/32.png) [@Brent\_D](https://www.ruby-forum.com/u/Brent_D)\ **Post date:** [July 18, 2006, 9:16pm UTC](https://www.ruby-forum.com/t/when-is-a-site-too-small-for-rails/98888/3 "2006-07-18T21:16:45Z")
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. ---
**Author:** ![Brent\_D](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/b9bd4f/32.png) [@Brent\_D](https://www.ruby-forum.com/u/Brent_D)\ **Post date:** [July 18, 2006, 9:16pm UTC](https://www.ruby-forum.com/t/when-is-a-site-too-small-for-rails/98888/4 "2006-07-18T21:16:54Z")
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](http://lists.rubyonrails.org/pipermail/rails/2006-January/010860.html) ``` - dan ``` – Dan K. [mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://www.dankohn.com/](http://www.dankohn.com/)tel:+1-415-233-1000 ---
**Author:** ![Brent\_D](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/b9bd4f/32.png) [@Brent\_D](https://www.ruby-forum.com/u/Brent_D)\ **Post date:** [July 18, 2006, 9:27pm UTC](https://www.ruby-forum.com/t/when-is-a-site-too-small-for-rails/98888/5 "2006-07-18T21:27:00Z")
> 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](http://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](http://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 ---
**Author:** ![Brent\_D](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/b9bd4f/32.png) [@Brent\_D](https://www.ruby-forum.com/u/Brent_D)\ **Post date:** [July 19, 2006, 1:31am UTC](https://www.ruby-forum.com/t/when-is-a-site-too-small-for-rails/98888/6 "2006-07-19T01:31:01Z")
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](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 ---
**Author:** ![Brent\_D](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/b9bd4f/32.png) [@Brent\_D](https://www.ruby-forum.com/u/Brent_D)\ **Post date:** [July 18, 2006, 9:49pm UTC](https://www.ruby-forum.com/t/when-is-a-site-too-small-for-rails/98888/7 "2006-07-18T21:49:50Z")
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.