VPS 利用:LXadmin lighttpd proxy设置

2009年12月19日星期六 | | |

VPS 的利用:LXadmin lighttpd proxy设置
 Please add the domain from your Lxadmin as in the wiki http://wiki.railsplayground.com/railsplayground/show/How+to+setup+a+rails+application and follow the steps below.

1. Check for the lighttpd modules in /etc/lighttpd/lighttpd.conf

vi /etc/lighttpd/lighttpd.conf

The following modules should be there in server.modules directive.

server.modules = (


If you didn't find any of the above modules, try to enable it.

For eg: If you didn't find mod_proxy, add "mod_proxy",
to /etc/lighttpd/lighttpd.conf

You'll only need to enable mod_proxy at RailsPlayground.

2. Add the following configuration to lighttpd vhost file

vi /etc/lighttpd/conf/lxadmin/lighttpd.yourdomain.com

proxy.balance = "fair"
proxy.server  = ( "/" =>
     ( ( "host" => "", "port" => 8001 ) ) )

Update the server.document-root variable to point to the /public directory of this application.

If you need multiple ports to be enabled, for cluster configuration

proxy.balance = "fair"
proxy.server  = ( "/" =>
     ( ( "host" => "", "port" => 8001 ),
     ( "host" => "", "port" => 8002 ) ) )
3. Change the ownership of your application directory to apache

chown apache:apache /home/admin/yourdomain.com -R
4. Restart lighttpd

/etc/init.d/lighttpd restart
5. Install the mongrel gem.

gem install mongrel
6. Start your mongrel

cd /home/admin/yourdomain.com (application directory)

mongrel_rails start -d -p 8001  -e production -P log/mongrel-1.pid
You should be running your application on mongrel now.

You may list the mongrel process using the command

ps auwx | grep mongrel
Important: Please note that lighttpd+mongrel will require more memory than lighttpd + fcgi setup.

--- title: Lighttpd inMenu: true directoryName: Documentation ---

*I'm sad to say that I have to recommend people not use lighttpd anymore.* The author hasn't updated the mod_proxy plugin and isn't providing too much support for the bugs it has. If you're running lighttpd and you constantly see 500 errors that are never recovered, then you should switch to Apache or another web server that can handle properly balancing backends.

h1. Using Lighttpd With Mongrel

It is possible to host an application with just Mongrel since it is able to serve files like a normal web server. Still, no matter how fast Mongrel gets it probably can't compete with something like lighttpd for serving static files. Because of this I've devised a simple way to setup a lighttpd+Mongrel setup that demonstrates clustering four Mongrel servers running the same application as backends.

This is very similar to a FastCGI or SCGI setup except that you're just using regular HTTP. Read through the "HOWTO":howto.html for information on other possible deployment scenarios.

h2. The Goal

What we want to do is put a lighttpd on the internet and then have it proxy back to one of four Mongrel servers.


This is actually really trivial and probably doesn't need a diagram but I got bored just writing it up.

How it all works is pretty simple:

# Requests come to the lighttpd server. # Lighttpd takes each request, and sends it to a backend depending

on how you configure it:

  • hash -- Hashes the request URI and makes sure that it goes to the same backend.
  • round-robin -- Just chooses another host for each request.
  • fair -- "Load based, passive balancing." No idea what that means, but if it's like the rest of lighttpd it probably means it will overload the first one and if that one's busy then it starts using the next ones.

# Each backend doesn't really care about any of this since it's just a web server.

h2. Lighttpd Configuration

For lighttpd you need to have *mod_proxy* in your server.modules setting:

server.modules = ( "mod_rewrite", "mod_redirect",

"mod_access", "mod_accesslog", "mod_compress", "mod_proxy")

Then you need to tell lighttpd where the other backends are located:

proxy.balance = "fair" proxy.server = ( "/" =>

( ( "host" => "", "port" => 8001 ), ( "host" => "", "port" => 8002 ), ( "host" => "", "port" => 8003 ), ( "host" => "", "port" => 8004 ) ) )

When I used lighttpd 1.4.9 and set proxy.balance="round-robin" I had an excessive number of 500 errors for no real reason. The "fair" setting seems to be the best, but if you have a large number of fairly random URIs you should try "hash" too.

*For the rest of this tutorial we'll assume you're running lighttpd on port 80.*

h2. Mongrel Configuration

Mongrel is pretty easy to setup with this configuration on either Win32 or Unix, but since lighttpd doesn't compile so easily on Win32 I'll just show the Unix method for starting it:

$ mongrel_rails start -d -p 8001 \

-e production -P log/mongrel-1.pid

$ mongrel_rails start -d -p 8002 \

-e production -P log/mongrel-2.pid

$ mongrel_rails start -d -p 8003 \

-e production -P log/mongrel-3.pid

$ mongrel_rails start -d -p 8004 \

-e production -P log/mongrel-4.pid

Now you should be able to hit your web server at port 80 and it'll run against one of your four Mongrels.

h2. Testing Stability and Performance

As I mentioned before proxy.balance="round-robin" had many stability issues in lighttpd 1.4.9 but how did I figure this out? Here's how you can do it.

You use "httperf":http://www.hpl.hp.com/research/linux/httperf/ to first hit each Mongrel backend with a large request set.

$ httperf --port 8001 --server \

--num-conns 300 --uri /test

$ httperf --port 8002 --server \

--num-conns 300 --uri /test

$ httperf --port 8003 --server \

--num-conns 300 --uri /test

$ httperf --port 8004 --server \

--num-conns 300 --uri /test

After each of these you're looking for the *Connection rate*, *Request rate*, *Reply rate*, and *Reply status*. You first look at the *Reply status* to make sure that you got all 2xx messages. Then look at the other three and make sure they are about the same.

Then you hit lighttpd with a similar request set to confirm that it handles the base case.

$ httperf --port 80 --server \

--num-conns 300 --uri /test

You should get no 5xx errors. In the case of round-robin there were about 60% 5xx errors even though the Mongrels were functioning just fine. The "hash" method didn't improve this test's performance since there's only on URI in the test. It seems the "fair" method is the best you can do right now.

Finally you hit lighttpd with a 4x rate to see if it could handle the theoretical limit.

$ httperf --port 80 --server \

--num-conns 10000 --uri /test --rate 600

It will most likely fail miserably and you'll probably see a few 5xx counts in the *Reply status* line but that's normal. What you're looking to do is keep moving --rate and --num-conns up/down until you get where the server is just barely able to accept the requests without slowing down (i.e. your *Request rate* matches your --rate setting). There will be a point where adding literally one more to your --rate setting causes the Request rate to tank. That's your setup's breaking point and is the actual requests/second you can handle.

h1. Insane Caching Power Magnet

Mongrel (as of 0.3.7) by default supports Rails style page caching in the RailsHandler? it uses to serve your applications. What this means is that if you do a page cached action (which writes a .html file as well as respond) then Mongrel will just serve up the cached page instead of bug Rails.

This does give you a large boost in performance, but still not nearly as much as if you had lighttpd doing the caching for you. The optimal configuration would be where lighttpd checks for cached pages and then served it directly as it already does with FastCGI.

There are some technical problems with this and the lighttpd mod_proxy, but thankfully I don't have to go into them because lighttpd now supports the "power magnet" and Cache Meta Language (CML). CML is a small bit of the Lua programming language that lets you script lighttpd and tell it when to cache or not. The power magnet feature of CML lets you put all requests through one CML script so that you can determine whether to cache or not.

h2. Configuration

In order to get everything to work right you'll need a few pieces of equipment and make sure they are enabled in your lighttpd build. The sample build was done on Debian so that everything would work including mod_rewrite, mod_memcache, mod_cml, and mod_redirect.

* lua50, liblua50-dev * libpcre3-dev * memcached * Finally make sure you configure with ./configure --with-lua --with-memcache

Debian people will need to follow these instructions from "www.debian-administration.org":http://www.debian-administration.org/articles/20 for installing from source, and will also need to add these lines to your /etc/apt/sources.list:

deb-src http://http.us.debian.org/debian stable main contrib non-free deb-src http://http.us.debian.org/debian unstable main contrib non-free deb-src http://non-us.debian.org/debian-non-US stable/non-US main contrib non-free

And then do the following:

# Make sure you don't have the source extracted in your current directory. # apt-get install devscripts debhelper build-essential fakeroot # apt-get update # apt-get source lighttpd # nano -w lighttpd-1.4.10/debian/rules ## DEB_CONFIGURE_EXTRA_FLAGS need have at the end: --with-lua --with-memcache # nano -w lighttpd-1.4.10/debian/lighttpd.install ## debian/tmp/usr/lib/lighttpd/mod_cml.so needs to be added here.

Then you're supposed to be able to follow the debian-administration docs but I haven't got it all working yet. Please clue me in if you get this compiled on Debian.

h3. lighttpd.conf

If it all builds right then you'll be able to use this nifty CML script that Bradley K. Taylor (from railsmachine.net) came up with. First you need to tweak your lighttpd.conf at the place where you have the mod_proxy setup from previous:

$HTTPhost? == "www.myhost.come" {

server.document-root = "/my/path/to/app/public" cml.power-magnet = "/my/path/to/app/config/power-magnet.cml" proxy.balance = "fair" proxy.server = ( "/" => ( ( "host" => "", "port" => 8001 ),

( "host" => "", "port" => 8002 ) ) )


This one just has two for simplicity. The big thing is the document root setting and the power-magnet.cml setting. I wouldn't put the power-magnet.cml in your public directory.

h3. power-magnet.cml

Now for the magic bit of Lua code that tells lighttpd what to do:

dr = requestDOCUMENT_ROOT?

if file_isreg(dr .. "maintainance.html") then

output_include = { dr .. "maintainance.html" } return CACHE_HIT


f = requestREQUEST_URI?

if f == "/" or f == "" then

file = dr .. "index.html"

elseif not string.find(f, "%.") then -- rewrite for cached pages

file = dr .. f .. ".html"


file = dr .. f


if file_isreg(file) then

output_include = { file } return CACHE_HIT


return 1 -- should be CACHE_MISS, but there's a bug in 1.4.10

Place this in the /my/path/to/app/config/power-magnet.cml like you configured above.

Now if you restart lighttpd and everything worked right you should be able to see the headers and tell if Mongrel or lighttpd is serving them. Use curl like this:

curl -I http://zedapp.railsmachine.net/ curl -I http://zedapp.railsmachine.net/admin

The second one should redirect and show a Mongrel header while the first one should show a lighttpd header.

h2. Memcached

The next installment of this document will tell you how to setup a memcached so that you can run the lighttpd on a different server from the Mongrel cluster. Right now they all have to reside on one machine.

h2. CML Tricks

Since Lua is a full blown and fast little language you can get pretty creative with it. For example you could have it check dates and times of files, look for processes that should be running, run commands, check the contents of a file, etc.

Take a look at the "Lua Reference Manual":http://www.lua.org/manual/5.0/ to see what it can do. Ruby people will probably like Lua.


0 评论:

所有文章收集于网络,如果有牵扯到版权问题请与本站站长联系。谢谢合作![email protected]