Multiple Applications Setup

Hi everyone!

I’ve just asked a question in the Rails forum:

http://www.ruby-forum.com/topic/111412#new

But I’ve been re-directed here for a more detailed answer :slight_smile: Anyway,
below is my original question(s).

My development-side question was answered already but I’m still
interested in learning more about the production side of things - eg -
whether people suggest using Pound or Apache, do I need multiple mongrel
clusters, etc.

I’ve been using Apache for years but I’m not really familiar with
configuring it outside common behaviour and if Pound is going to be a
little easier I might go with that, if it will do the same thing?

My main concern is how to host multiple applications on a single server

  • I am a website developer so I’ll likely end up with a lot of sites
    running on a single server. Do I need a separate application (and
    mongrel cluster) for each of these?

Anyway, whatever help you can provide would be greatly appreciated!

Thanks
Jay


Hi everyone!

I’m just getting started with RoR - I’m a bit behind the game! Anyway, I
have several website I want to move over to this format and which I want
to host on a single Linux Virtual Machine (that’s what my hosting is at
the moment, if I have to upgrade to a dedicated server, so be it). So
I’m a little confused about how this all fits together - most of the
info I’ve read seems to be geared towards a single application, rather
than multiple applications.

So I guess my question is, what setup should I use for development and
production? I have been considering Apache or Pound, with a mongrel
cluster running several Ruby instances. But do I need this much on the
development side? Or can I just use WebBrick on different ports and be
done with thinking about it? When it comes to production what do I do
here? Do I need a mongrel cluster for each application? Or can you make
each cluster run more than one application, so Apache/Pound can redirect
to the same place for all incoming requests?

Anyway, any help with setting this up would be most appreciated :slight_smile:

Thanks
Jay

There are a lot of ways you can go, and it’ll depend on your apps, what
OS
and resources are available to you, whether you need utmost performance,
or
easiest setup and maintenance, etc.

From what I’ve observed, Nginx, Swiftiply, and Mongrel/Mongrel_cluster
are
the way to go as sort of the best all-software setup. We are migrating
to
this, as we have intense traffic - both in number of requests and
volume/bandwidth expected. However, we’ll have F5 BigIP load balancers
in
front as well, so in production will be using those for load balancing.

Currently though, for development and testing, we’re using Pound, partly
because it was trivial to set up. We have 4 Rails apps that work
together
in an SOA style architecture, as well as serving a fair chunk of static
content. We use RESTful routes, and essentially a path prefix, so the
Pound
configuration was just extremely simple. Each Rails app gets a port
range
for X number of Mongrels (via Mongrel Cluster) on a given machine, and
then
Pound directs traffic and load balances across all that. Works quite
well,
and is nice and easy to maintain. Pound does bog down at a certain
level of
traffic, but for development work, and main testing purposes it is quite
fine. Our production setup is more complicated, and involves hardware
load
balancing via the F5’s as mentioned, and we’ll be using Nginx in a few
ways
as well, Pound will be out, etc. We don’t use Apache, but you may or
may
not need it depending on your needs/constraints/requirements (for
example,
if you need a particular Apache module, or that’s all a VPS can give
you, or
whatever).

On 6/11/07, James H. [email protected] wrote:

  • I am a website developer so I’ll likely end up with a lot of sites
    Hi everyone!
    production? I have been considering Apache or Pound, with a mongrel
    Jay


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


Chris B.
[email protected]

On 6/12/07, James H. [email protected] wrote:

In terms of development I think using Pound might be a bit
overkill for the moment as well, until I get lots of sites going I can
just start up mongrels manually.

On a 150 Mb VM, you may not be able to squeeze more than one Mongrel
in. And if one request stalls in that single Mongrel, your entire site
goes unresponsive (Mongrel w/ Rails is essentially a single-threaded
process).

For any decent uptime, you need at least two Mongrels and a software
load balancer of some sort. Some sort of monitoring for crashing
Mongrels / endless loops / memory leaks is useful. Also, 150 Mb of RAM
may prove insufficient for more than a single Mongrel.

Have a look here: http://studios.thoughtworks.com/rubyworks. This may
be about right for your needs, if you reduce the number of Mongrels in
the cluster from 4 to 2.


Alex

Hi Chris

Thanks very much for your reply. In terms of OS I’m looking at using
Ubuntu. Apps-wise I’m not sure yet, but I’m hoping to keep the number of
apps down to a minimum by sharing between sites - ie - 2+ simple sites
run off the same app but with different content/layouts/etc. Not sure
how this is going to work yet, but it must be possible? In terms of
resources I’m (planning on) using the most basic VM option available
through www.bytemark.co.uk, that is, 150MB RAM, until I need more and
then I’ll change.

I’d never heard of Nginx before but it certainly sounds like a good
solution. So let me get this straight - on the development side you have
Pound (load balancing, traffic direction) running in front of N mongrel
clusters. On your production you have hardware load balancers, with
Nginx as your main server and again N mongrel clusters. Oh for a
whiteboard?!

I don’t think I’ll need such a complex production system as it sounds
like you’re getting a lot more traffic than I am expecting, at least
initially. In terms of development I think using Pound might be a bit
overkill for the moment as well, until I get lots of sites going I can
just start up mongrels manually.

Anyway, thanks for your help - I think I have more of an idea where I am
going now and I’ll certainly have a look at nginx as a possible
production server.

Thanks
Jay

Hi Alex

Thanks for your comments - I didn’t realise I sailing so close to the
wind! I was planning on having a fair few apps running and multiple
mongrels serving each of these - clearly this isn’t going to be possible
on this setup.

I am a bit annoyed that no-one has alerted me of this problem earlier,
especially the server company, who I am just about to sign up with.
Hmmm, not sure what to do now, as I say I have multiple websites, which
I’m looking to run as several apps - and as they are client sites I
can’t really afford for them to be slow/holding each other up. Perhaps
we’re looking at a dedicated server…

Are there some stats somewhere - eg - memory usage for mongrel - that I
look at to see what might work best? Or do you have any suggestions?
Other than the Thought Works one, I’m looking at that now :slight_smile:

Thanks
Jay

On some of the larger sites we host doing 20-30 million hits a day,
we’re running 16 mongrels on number of dedicated boxes. Each mongrel
uses approx 70 Megs of RAM. Nginx doesn’t even register for ram
utilization.

We recommend to our clients at-least 512 megs of ram for Virtual
Servers and 2-4 Gigs of Ram for dedicated servers. That’s been a
winning combination so far.

Jesse P.
Blue Box Group, LLC

p. +1.800.613.4305 x801
e. [email protected]

Hi Alex/Jesse

Thanks for your responses - clearly I have grossly underestimated the
loads involved in running a single RoR app, let alone a fleet of them!

So I am stuck :frowning: Can anyone think of a cost effective and maintainable
way to host my sites, described below?

I have several sites (about 10) which I have developed on behalf of
clients - mostly small businesses near where I live. The sites vary
greatly in complexity - there are entirely static sites, mostly static
sites (with the occasional dynamic page), mostly dynamic sites (where
the page content is generated on the fly) and entirely dynamic sites,
where the user can login, create new pages on the site, create news
items which will be displayed on the home and news pages, etc. None of
these sites receive a huge amount of traffic - the total for all the
sites is about 10,000 page requests per day.

So I was thinking I could host each of these as a separate RoR app - how
wrong I was :slight_smile: So now I am thinking I could host the whole lot as a
single app, with a couple of mongrels running the whole shebang. But
having considered this I am presented with a few problems: db separation

  • each dynamic site should (ideally) have it’s own db; controller/action
    selection - two requests selecting the same controller/action on
    different sites/domains should (probably) select different controllers,
    even if they all inherit from some default controller; I can’t think of
    any others now, but I’m sure there are a few.

Previously I’ve been using plain, old CGI to do all this. Yes I know my
setup is archaic, but at least I have realised that now and am trying to
do something about it :slight_smile: So currently most of my page URLs are something
like:

http://www.mydomain.com/cgi-bin/controller.cgi?p=action

I am keen to get all of my sites using the RoR style of URL formatting,
since (for starters) I think it is more user friendly:

http://www.mydomain.com/controller/action/

I’d love to use RoR for the dynamic sections of the sites - I’ve only
been using it for a couple of days and already I feel like I’m more
productive. But is this going to be possible?

Anyway, any and all suggestions gratefully received - I think I’ve dug
myself a bit of a hole, now I just need to find some way out!

Thanks
Jay

On 6/12/07, Jesse P. [email protected] wrote:

Each mongrel uses approx 70 Megs of RAM.

50 to 80 is the range I’ve seen. You should also set up the load
balancer in such a way that it never sends more than one request at a
time to any Mongrel process, when a Mongrel is overloaded even for a
few minutes, it will allocate another up to 50 Mb and never release it
back.

512 Mb is the minimum you need for 4 Mongrels, which is usually enough
to exhaust CPU / system bus speed limits on a commodity Dual Core box.
In equally vague terms, it should usually be enough to handle a normal
slashdotting (sustained load of 10-20 hits per second) with a
reasonably well-tuned Rails app and no page caching. Assuming your
database is on another box.

Having said that, there are applications and applications. Something
like a blog (99% page-cached traffic) can be hosted on a 100 Mb VM
with a single Mongrel behind Apache.


Alex Verkhovsky
RubyWorks

Hi Chris

Thanks for your post - much appreciated. So LiteSpeed can handle
concurrent connections to different apps? But with less memory usage
than Apache+mongrel? That might be what I am after :slight_smile:

Quick question on a related subject - does anyone know how much memory a
single MySQL connection uses? So if (say) I had ten websites running in
separate RoR apps with a MySQL connection to each, what is my memory
footprint likely to be? Just trying to get a feel for what solutions are
possible/realistic.

Cheers
Jay

Hi Jay,

I’ve a TON less experience than these guys with Rails deployment, so
take what I’m suggesting with a grain of salt. All my Rails apps are
internal, not external, so I’m not seeing traffic like you are.
However, with that said…

I’ve had a LOT of (good) luck with using LiteSpeed
(http://www.litespeedtech.com) as my web server to serve both static
and dynamic content. The memory footprint is much less than
Apache+mongrel, and it just runs; I don’t have to monitor it for
zombie mongrel processes. They have a custom interface/API (LSAPI)
that alows the web server to talk to Ruby, and it’s FAST…

Take a look and see if that might be a solution in the context of your
VPS…


Best Regards,

Chris

It all depends on how similar these sites are and if they need to
share code?

If each site is completely separate I’d probably want to look at the
option of a VPS for each site, perhaps with a single vps serving the
dbs for all the sites. With the number of sites you are talking about
it might work out cheaper to have a dedicated machine and use xen to
slice up your own VPS. Doing it this way mean that each site has
dedicated resources, each site would be easier to scale, and you will
only need to scale the site that is getting the traffic.

If your sites are fairly small, and unlikely to get high traffic, you
might want to look at a shared host? Its not ideal, and you would have
to plan how you would scale up should you need to in the future, but
it would be much cheaper.

Steve

On Jun 13, 4:13 pm, James H. <ruby-forum-incom…@andreas-

On a slightly different note one of my friends suggested the following:

You can probably make the app (apache, lighttpd or whatever) which is
calling mongrel or the .fcgi re-write URLs so that e.g.
http://www.site.com/:controller/:action

looks like:
http://…/:site/:controller/:action

and modify routes.rb, as I’ve done this myself, to skin an identical
site in different ways. Maybe you could even re-write as below, saving
yourself the route changes and maximising the separation:
http://…/:site_controller/:action

Which seems like a good plan? That way I can create controllers for each
site and I can (presumably) inherit from a default controller for each
case. What do people think? Does this actually help me at all?

Thanks
Jay

Hi Steve

Thanks for your reply. I am currently AT the shared host stage and I’m
looking to move forward from there. None of the sites receive a massive
amount of traffic at the moment but I have a few sites in the pipeline
that might receive a bit more.

Also, I am looking to share as much code as possible. I’ve written some
functions which I use in most of my code and I need these to be
available to all the sites, rather than maintaining several different
versions!

Anyway, so that is where I am at. Quick question - does anyone know how
much memory a connection to MySQL uses? I’ve ruled out the multiple
mongrels accessing multiple DBs on the premise that it will use too much
memory, but if MySQL does not use that much memory this might be worth
going for? Still a bad solution to a bad problem, but it looks like I’ll
have to compromise somewhere…

Cheers
Jay

Chris B.

I was wondering if you could give a little more detail on your Pound
setup, specifically:

1.) How much load/traffic till it started to bog down
2.) What were the specs of the machine/VM you were running it on?

We’re looking at Pound for starters and would like to the some numbers
other people are getting before performance starts taking a hit.

Hi Chris

Actually I haven’t setup anything yet, I was trying to determine the
same as you - whether the VM I am considering (150MB) has any chance of
running the application I am considering.

Cheers
Jay

Jay,

In your situation I probably would go with Litespeed too. It’s easier
to setup sites (web interface) and it handles all the processes behind
the curtain for you. It will open ruby processes for each Rails site
you do (30-70Mb each) so your RAM requirements are surely higher than
150MB. I don’t have your full numbers but I’d say 512Mb should
probably do it. On the hosting side I would recommend going with
Slicehost ($38 for 512, $70 for 1024) which I’m testing right now and
it’s been great for me and have heard really good things about it. And
if you don’t have lots of sysadmin experience there is a set of
tutorials [1] that is great to set up a secured Ubuntu server with
Ruby, Rails, PHP, LiteSpeed and MySQL.

Hope this helps,

Adrian M.

[1] http://www.usefuljaja.com/2007/4/ubuntu-setup-page-1

On Jun 13, 9:08 am, James H. <ruby-forum-incom…@andreas-

Hi Adrian/Chris

Thanks for your responses.

Chris: Yes, I am worried about the whole same app/same database model
too. Seems like a bad plan to me, hence why I have stayed away from it
thus far.

I think you’re right - providing the functionality I require in the form
of a plugin is the correct way to go. I’m never going to be able to
write no new code at all, the important thing is to reuse the difficult
stuff :slight_smile:

Adrian: I’ll look into Slicehost now. $38 seems very cheap for 512, what
am I missing? Apart from a box to sign in :slight_smile:

I agree LiteSpeed sounds like the best option server-wise - I’d never
heard of it before now but seems fairly self-explanatory and worth
looking into.

Cheers
Jay

replied in line

On Jun 15, 12:13 pm, James H. <ruby-forum-incom…@andreas-
s.net> wrote:

Also, I am looking to share as much code as possible. I’ve written some
functions which I use in most of my code and I need these to be
available to all the sites, rather than maintaining several different
versions!

Sorry I didn’t make myself clear.

If they are sharing code, in terms of needing the same functions, you
would be better to extract that functionality into plugins.

When I said sharing code, I really meant sharing data, meaning that
they needed the same database.

I’d worry about having unrelated apps running as part of the same
mongrel cluster accessing the same data base.

Anyway, so that is where I am at. Quick question - does anyone know how
much memory a connection to MySQL uses? I’ve ruled out the multiple
mongrels accessing multiple DBs on the premise that it will use too much
memory, but if MySQL does not use that much memory this might be worth
going for? Still a bad solution to a bad problem, but it looks like I’ll
have to compromise somewhere…

Not sure about memory use, but doubt its significant. Take a look at:
http://drnicwilliams.com/2007/04/12/magic-multi-connections-a-facility-in-rails-to-talk-to-more-than-one-database-at-a-time/

Steve

Jay,

You have full control over your VPS: root access, add/remove packages,
etc. The only thing you are missing is the full power to the HW since
you are sharing it with other people. But you also pay a fraction so
it evens up. And you can buy backups and you get RAID1 for free so it
is hard to match value on a dedicated server. BTW, if you need that
the best value I’ve found (and using) is cari.net [1], you can get
started for $60/mo. Although I would highly recommend RAID1 and
backups at the very least.

Now on the development side I gotta say that you shouldn’t have to go
through the hassle of setting up one app for multiple domains because
of the cost. A VPS like we talked before should handle multiple apps.
BTW, SliceHost[1] let’s you resize your VPS up or down (256 <-> 512 <-

  1. in literally minutes so getting the amount of resources you
    need shouldn’t be a problem. Now,if you really need an app to handle
    multiple domains with different logic for each url you can deinitely
    do it but it won’t be an easy road. I have a framework that does
    something similar and I can tell you that Rails wasn’t made to make
    your life easier down that road. If you really need more info on that
    we can talk some more other time.

Hope it helps,

AEM

[1] http://slicehost.com

On Jun 15, 9:36 am, James H. <ruby-forum-incom…@andreas-

Hi Adrian

Thanks for your reply again.

Sounds fair enough, the VPS seems a good option and without the memory
limitations I was having with the other hosting package. My one problem
with Slicehost is that they are based in the US, where as most of the
clients I am working for will be based in the UK - do you perceive that
being a problem? I agree on the backups issue - I’ve had problems with
that before, it’s not worth risking it.

I entirely agree with your comments re development - when I first
started out with Rails I hadn’t even conceived the idea that I might
have to serve multiple sites via a single app.

I guess the only way to tell with this stuff is to suck it and see. So,
that said, I’ll probably move some of the less important sites across
first and see how they perform. Then I’ll move the bigger ones over one
and a time. Hopefully 1) everything won’t come crashing down around my
ears 2) if it does it can be fixed by using the next size of VPS.

Anyway, thanks for your help, I appreciate the time you’ve spent
advising me. I owe you a pint :slight_smile:

Cheers
Jay

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs