Can someone please explain Lighttpd + Mongrel + Rails


#1

I know that Mongrel is a web server that hosts rails applications. But
i don’t understand what part Lighttpd (or Apache) has in the setup. I
know that you can use Mongrel on its own. What does Lighttpd improve
on?

Thanks,
Chris


#2

On Apr 20, 2006, at 16:19, Alan F. wrote:

A bit like putting tomcat instance behind Apache. Apache would serve
the static stuff quickly, but delegate to tomcat as an appserver.
With
the rails model, I think you can either do it tat way, or the other
way round. Instead of the static at the front, delegating back, the
dynamic server is at the front, delegating static serves to the asset
server (which is, IIRC a config parameter somewhere).

Interesting, could anyone explain how to do this?

Alternatively, I could be talking total nonsense.

Haaahaha

– fxn


#3

Chris R. wrote:

I know that Mongrel is a web server that hosts rails applications. But
i don’t understand what part Lighttpd (or Apache) has in the setup. I
know that you can use Mongrel on its own. What does Lighttpd improve
on?

Some folks might use Lighttpd as an asset server. This would serve any
static content (Light is FAST for that). Mongrel would be used as the
app server, running the rails app to serve any dynamic content.

A bit like putting tomcat instance behind Apache. Apache would serve
the static stuff quickly, but delegate to tomcat as an appserver. With
the rails model, I think you can either do it tat way, or the other
way round. Instead of the static at the front, delegating back, the
dynamic server is at the front, delegating static serves to the asset
server (which is, IIRC a config parameter somewhere).

Alternatively, I could be talking total nonsense.

Alan


#4

Lighttpd + Mongrel instructions are available on Mongrel’s main page.

I’m working up Apache instructions for Windows users at the moment.


#5

Xavier N. wrote:

On Apr 20, 2006, at 16:19, Alan F. wrote:

A bit like putting tomcat instance behind Apache. Apache would serve
the static stuff quickly, but delegate to tomcat as an appserver.
With
the rails model, I think you can either do it tat way, or the other
way round. Instead of the static at the front, delegating back, the
dynamic server is at the front, delegating static serves to the asset
server (which is, IIRC a config parameter somewhere).

Interesting, could anyone explain how to do this?

Alternatively, I could be talking total nonsense.

Haaahaha

– fxn

Phew! not nonsense.

See config/environments/production.rb

Enable serving of images, stylesheets, and javascripts from an asset

server

config.action_controller.asset_host = “http://assets.example.com

Alan


#6

Thanks for the response.

So what you’re saying is that Lighttpd or Apache are only good if there
exists static content? Surely they have another purpose? I mainly write
webb applications that have very little to no static content. Are you
saying that Apache or Lighttpd are useless in that situation,

Thanks,
Chris


#7

On 20/04/06, Alan F. removed_email_address@domain.invalid wrote:

Chris R. wrote:

I know that Mongrel is a web server that hosts rails applications. But
i don’t understand what part Lighttpd (or Apache) has in the setup. I
know that you can use Mongrel on its own. What does Lighttpd improve
on?

Some folks might use Lighttpd as an asset server. This would serve any
static content (Light is FAST for that). Mongrel would be used as the
app server, running the rails app to serve any dynamic content.

The other main benefit of sitting Mongrel behind Lighttpd is that you
can then run multiple instances of Mongrel serving up the same app and
configure Lighttpd to load balance between them. It looks like Apache
2.2 has support for doing the same thing that I’ll be looking into in
the future.

http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html

Paul.


#8

Mongrel is not a full fledged webserver at this point. Assuming it
follows the Tomcat tradition, it probably never will be. It is
designed as a rails deployment webserver, not a Apache/Lighty
replacement.

If you need features it does not have, you need to front-end it.

AIUI, it does not currently do: load-balancing, ssl, web-single login
plugins(nor most other standard plug-ins), server static content at
high-speed, etc.

So, come up with a feature list of what you need for a webserver to
do. Then ask if Mongrel can do them all. If not, you need to pick a
front-end, or even avoid Mongrel altogether.

Greg

On 4/20/06, Chris R. removed_email_address@domain.invalid wrote:


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


Rails mailing list
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails


Greg F.
The Norcross Group
Forensics for the 21st Century


#9

2006/4/20, Xavier N. removed_email_address@domain.invalid:

On Apr 20, 2006, at 16:30, Brian H. wrote:

Lighttpd + Mongrel instructions are available on Mongrel’s main page.

Sure, but the setup we were talking about puts Mongrel in front of
lighttpd, not behind.

in front of/behind… well it’s just a matter of point of view,
depending if you’re in server side or client side :slight_smile:

-- Jean-François.

#10

On Apr 20, 2006, at 16:30, Brian H. wrote:

Lighttpd + Mongrel instructions are available on Mongrel’s main page.

Sure, but the setup we were talking about puts Mongrel in front of
lighttpd, not behind.

– fxn


#11

If all application requests are forwarded to Mongrel then how does
load-balancing functionality of Lighttpd affect anything? is it only
for load balancing static content?

Chris


#12

Hrm,

So is Mongrel an alternative to FastCGI? If so how do they compare
in speed and resource usage to each other?


#13

On Apr 20, 2006, at 8:16 AM, Chris R. wrote:

If all application requests are forwarded to Mongrel then how does
load-balancing functionality of Lighttpd affect anything? is it only
for load balancing static content?

Lighttpd is configured to send app requests to several Mongrels.


– Tom M.


#14

I really like Mongrel because it’s a lot easier to manage. Performance
seems to be better than FastCGI in my tests, but I encourage you to do
your
own because every situation is different. Mongrel is the best
alternative
if you’re running on Windows like myself.


#15

So what are the scaling implications of using Lighty to proxy to Mongrel
vs.
Lighty pointing to FastCGI processes? I’m working on an app that I
expect to
scale to at least a couple of app servers, and I’ve just been planning
on
using lighty as a load-balancer between several FastCGI processes
running on
each app server. Is Mongrel a faster/more stable/lighter alternative to
this? I’ve seen some of the Mongrel performance tests, and it didn’t
seem to
be much of a step up in performance. But, I haven’t done a very in-depth
study of it yet (still in design/development mode), so I could easily,
and
probably am, incorrect.

Thanks!

Matt


#16

On Apr 20, 2006, at 9:54 AM, Matt W. wrote:

So what are the scaling implications of using Lighty to proxy to
Mongrel vs. Lighty pointing to FastCGI processes? I’m working on an
app that I expect to scale to at least a couple of app servers, and
I’ve just been planning on using lighty as a load-balancer between
several FastCGI processes running on each app server.

Good plan.

Is Mongrel a faster/more stable/lighter alternative to this?

It’s easier to set up because it doesn’t require FCGI support.

I’ve seen some of the Mongrel performance tests, and it didn’t seem
to be much of a step up in performance.

Depends on when it was tested, and what was being tested. :slight_smile:


– Tom M.


#17

Tom,

I’m no sysadmin (but I’m trying to be one anyway), so sorry for bugging
you
:wink:

Since Lighty has FastCGI support baked in, in what case would you use
Mongrel instead of just using FCGI with Lighty? Would this primarily be
of
use if you were using another webserver like Apache that’s known to have
problematic FCGI support? In the Apache case, I’m assuming that you
would
use Apache to proxy directly to Mongrel instead of using Lighty as an
intermediary between the two… Is this correct?

If so, I guess I’ll go ahead with my original plan. I’ve been watching
Mongrel and wondering if it was an advantageous alternative to FCGI…

Thanks!

Matt


#18

Chris R. wrote:

If all application requests are forwarded to Mongrel then how does
load-balancing functionality of Lighttpd affect anything? is it only
for load balancing static content?

I think you’re a little confused Chris, load-balancing is when you
spread multiple requests across multiple services that answer that
request. Lighttpd load balances mongrel or fast-cgi requests buy
spreading them evenly among several mongrel or fast-cgi servers.
Because a single rails process can only process one request at a time,
having multiple servers means you can answer multiple requests at the
same time. Hence, a response time improvement when under a high load of
requests.


Matthew B. :: removed_email_address@domain.invalid
Resume & Portflio @ http://madhatted.com


#19

On 4/20/06 9:00 AM, “Chris R.” removed_email_address@domain.invalid wrote:

I know that Mongrel is a web server that hosts rails applications. But
i don’t understand what part Lighttpd (or Apache) has in the setup. I
know that you can use Mongrel on its own. What does Lighttpd improve
on?

Mongrel does the Ruby dynamic requests well and can server static files
pretty fast, so running smallish sites on just Mongrel is a good choice.
But, if you have a large amount of content then your strategy has to be
putting Mongrel behind some other webserver that is faster.

This is the same strategy when doing Tomcat behind Apache. Apache does
some
caching and serves static files like images and such, and then proxies
to
Tomcat for anything dynamic.

The interesting addition over Tomcat is that Ruby on Rails provides
excellent page caching and fragment caching. This means that once your
fronting webserver is configured correctly you can have Rails write the
page
rendering results to disk and then your web server will service future
requests from static files.

This kind of caching increases performance tremendously.

In short, Lighttpd or Apache or Litespeed are used to do two things:

  1. Serve any static content without talking to Mongrel (including cached
    pages).
  2. Load balance to a group of Mongrel servers for better parallel
    response.

Zed A. Shaw


http://mongrel.rubyforge.org/


#20

On 4/20/06 12:54 PM, “Matt W.” removed_email_address@domain.invalid wrote:

So what are the scaling implications of using Lighty to proxy to Mongrel vs.
Lighty pointing to FastCGI processes? I’m working on an app that I expect to
scale to at least a couple of app servers, and I’ve just been planning on
using lighty as a load-balancer between several FastCGI processes running on
each app server. Is Mongrel a faster/more stable/lighter alternative to this?
I’ve seen some of the Mongrel performance tests, and it didn’t seem to be much
of a step up in performance. But, I haven’t done a very in-depth study of it
yet (still in design/development mode), so I could easily, and probably am,
incorrect.

First, there needs to be a distinction between “performance” and
“scalability”. Performance is how fast your current deployment can
answer
requests. Scalability is how you can increase that performance by
adding
resources. Not lecturing just clarifying so I can focus the discussion.

For performance Mongrel performs as well as FastCGI in my applications,
but
you really need to do your own evaluation. I’d start with Mongrel since
the
setup is easier and then try FastCGI if you don’t get the speed you
need.
Also, use httperf to do your measurements.

One advantage that Mongrel has over FastCGI is that it’s Handlers
framework
means you can move dynamic content which doesn’t use much of the Rails
API
into a Handler that is serviced directly with Mongrel. This gives you
quite
a few options for tuning your application where it’s needed.

For scalability Mongrel wins since it’s just HTTP. If you try to find
load
balancing options for FastCGI you’re pretty much stuck with plain TCP
balancers. For HTTP there’s a mountain of experience and tools related
to
scaling out to larger installations. This means you can start small
with
just a single box, a web server, and a few Mongrel servers, and then
expand
with various options later when you see the need.

Zed A. Shaw


http://mongrel.rubyforge.org/