Apacheの前にあるLighttpdのもう一つの利点

Question

あるサイトで読んだのですが、Lighttpd を Apache の前に置くことのもう 1 つの利点は、子プロセスの数が少ないことです。Lighttpd はキープアライブとクライアント要求を処理し、Apache の子プロセスは Lighttpd と Apache 間の通信のレイテンシが非常に低いため、動的ページをより速く提供できるようになります。リンクを見つけようとしているのですが、なかなか見つかりません。

Given that I already have a dedicated Lighttpd server for my static contents (img, vid, css, js, html, etc.) and another dedicated Apache server for my dynamic pages (php), I would like to implement this technique if it really has some performance gain.

1) Has anybody put a Lighttpd in front of Apache for the same purpose as explained above?
2) Is there really a performance gain on this? How much?
3) What about the overhead of Lighttpd handling down the request to Apache, is it really worth it?

Thanks!

Answer 1

1. We had lighty serving static content, and forwarding the dynamic requests to Apache on the same server but listening on another port
2. the "forward to apache for dynamic" was not done for the purpose of performance, but just to have a single server from the point of the client, serving everything. However if you can avoid excess connections to Apache, it's a good side benefit. More connections = more processes = more memory (especially with mod_php). So, no numbers, sorry.
3. the overhead seemed negligle compared to the hog that is Apache

That said, you should consider the Varnish reverse proxy instead of (or in front of) lighty as your frontend. It's very fast and efficient. Especially interesting for caching dynamic pages (or page fragments, using ESI), it helps reducing the backend load and absorbing the traffic spikes.

And possibly use nginx (with PHP-FCGI) as a backend instead of Apache (although it's a more complicated task than adding a Varnish frontend) (nginx can be used as frontend too, but isn't as good as a dedicated reverse proxy like Varnish). Disclaimer: I don't have nginx experience ;)

Answer 2

I have used to be in the same situation, suing lighttpd next to apache)for reducing load on apache.

It's better to serve static content with a light web server, as it requires less resources. Also have to mention, that PHP requires apache to run in pre-forked mode, which disables apache from running efficiently. You can distribute the load over to two, differently set up web servers, each handling the traffic it's best in.

Some implementation notes:

You have three options:

1. modify your code and segment traffic on IP layer
2. don't modify your code and segment traffic on application (http) layer
3. get one of the web servers to pass requests coming to the other web server for actual serving

The first is quicker, the second requires less configuration, the third is like a mule.

I would not consider the third option if I were you, as it comes with a configuration nightmare, also, if you misconfigure something at the first web server, nothing will work and it's harder to spot where the problem is.

In the past, I needed to have a solution urgently, so I went with option 2, and utilized a reverse proxy called pound to segment requests upon static/dynamic content and distribute the load to the two different web servers.

動作しますが、HTTP コンテンツを積極的に監視する必要があり、パフォーマンスに影響を及ぼします (追加のデーモンが実行されます)。

オプション 2 では、静的コンテンツ用の追加 IP (static.domain.org) を利用してパフォーマンスを向上させ、クライアントがコンテンツを参照するためにこの static.domain.org を参照するようにすることができます。リバース プロキシは依然として必要ですが、プロキシはリクエストの Host: ヘッダーをチェックする必要がないため、処理が速くなります。

参考までに、pound の設定スニペットを以下に示します。

ListenHTTP 
        Address 195.175.71.17
        Port 80
        Client 30
        RewriteLocation 2

        Service
                HeadRequire "^[Hh]ost:\s*www.nasa.gov$"
                URL "^/static/content"
                BackEnd
                        Address 127.0.0.1
                        Port 81
                        TimeOut 300
                End
        End
        Service
                HeadRequire "^[Hh]ost:\s*www.nasa.gov$"
                BackEnd
                        Address 127.0.0.1
                        Port 80
                        TimeOut 300
                End
        End
ListenHTTP