Ein weiterer Vorteil von Lighttpd gegenüber Apache

Question

Ich habe auf einer Site gelesen, dass ein weiterer Vorteil von Lighttpd vor Apache die geringere Anzahl von untergeordneten Prozessen ist. Lighttpd verarbeitet Keep-Alive- und Client-Anfragen, während untergeordnete Prozesse von Apache dynamische Seiten schneller bereitstellen können, da die Kommunikation zwischen Lighttpd und Apache eine sehr geringe Latenzzeit aufweist. Ich versuche, den Link zu finden, aber es gelingt mir nicht.

Da ich bereits einen dedizierten Lighttpd-Server für meine statischen Inhalte (Bild, Video, CSS, JS, HTML usw.) und einen weiteren dedizierten Apache-Server für meine dynamischen Seiten (PHP) habe, würde ich diese Technik gerne implementieren, wenn sie wirklich eine Leistungssteigerung mit sich bringt.

1) Hat jemand für den gleichen Zweck wie oben beschrieben ein Lighttpd vor Apache gesetzt?
2) Bringt das wirklich eine Leistungssteigerung? Und wie viel?
3) Wie hoch ist der Aufwand, der durch die Weiterleitung der Anfrage an Apache durch Lighttpd entsteht? Lohnt sich das wirklich?

Danke!

Answer 1

1. Wir haben statische Inhalte leicht bereitgestellt und die dynamischen Anfragen an Apache auf demselben Server weitergeleitet, der jedoch auf einem anderen Port lauschte
2. Die „Weiterleitung an Apache für dynamische“ wurde nicht aus Leistungsgründen durchgeführt, sondern nur, um vom Client aus einen einzigen Server zu haben, der alles bedient. Wenn Sie jedoch übermäßige Verbindungen zu Apache vermeiden können, ist dies ein guter Nebeneffekt. Mehr Verbindungen = mehr Prozesse = mehr Speicher (insbesondere mit mod_php). Also keine Zahlen, tut mir leid.
3. der Aufwand schien vernachlässigbar im Vergleich zu dem Schwein, das Apache ist

Das heißt, Sie sollten den Varnish Reverse Proxy anstelle von (oder vor) Lighty als Frontend in Betracht ziehen. Er ist sehr schnell und effizient. Besonders interessant für das Zwischenspeichern dynamischer Seiten (oder Seitenfragmente, mit ESI), da er hilft, die Backend-Last zu reduzieren und die Verkehrsspitzen abzufangen.

Und verwenden Sie möglicherweise nginx (mit PHP-FCGI) als Backend anstelle von Apache (obwohl dies eine kompliziertere Aufgabe ist als das Hinzufügen eines Varnish-Frontends) (nginx kann auch als Frontend verwendet werden, ist aber nicht so gut wie ein dedizierter Reverse-Proxy wie Varnish). Haftungsausschluss: Ich habe keine Erfahrung mit nginx ;)

Answer 2

Ich war schon einmal in der gleichen Situation und habe Lighttpd (neben Apache) verklagt, um die Belastung von Apache zu reduzieren.

Es ist besser, statische Inhalte mit einem leichten Webserver bereitzustellen, da dieser weniger Ressourcen benötigt. Außerdem muss erwähnt werden, dass PHP erfordert, dass Apache im Pre-Fork-Modus ausgeführt wird, was Apache daran hindert, effizient zu laufen. Sie können die Last auf zwei unterschiedlich eingerichtete Webserver verteilen, von denen jeder den Datenverkehr verarbeitet, für den er am besten geeignet ist.

Einige Implementierungshinweise:

Sie haben drei Möglichkeiten:

1. Ändern Sie Ihren Code und segmentieren Sie den Verkehr auf der IP-Ebene
2. Ändern Sie Ihren Code nicht und segmentieren Sie den Verkehr nicht auf der Anwendungsebene (http).
3. Lassen Sie einen der Webserver Anfragen an den anderen Webserver weiterleiten, um diese tatsächlich zu bedienen.

Das erste ist schneller, das zweite erfordert weniger Konfiguration und das dritte ist wie ein Maultier.

Ich würde an Ihrer Stelle die dritte Option nicht in Betracht ziehen, da sie einen Konfigurationsalptraum mit sich bringt. Darüber hinaus funktioniert gar nichts, wenn Sie beim ersten Webserver etwas falsch konfigurieren, und es ist schwieriger, das Problem zu ermitteln.

In der Vergangenheit brauchte ich dringend eine Lösung, also entschied ich mich für Option 2 und nutzte einen Reverse-Proxy namensPfundum Anfragen nach statischem/dynamischem Inhalt zu segmentieren und die Last auf die beiden verschiedenen Webserver zu verteilen.

Obwohl es funktioniert, ist eine aktive Überwachung des HTTP-Inhalts erforderlich, was sich negativ auf die Leistung auswirkt (ein zusätzlicher Daemon wird ausgeführt).

Mit Option 2 können Sie eine bessere Leistung erzielen, indem Sie eine zusätzliche IP für statische Inhalte (static.domain.org) verwenden und die Clients für den Inhalt auf diese static.domain.org verweisen lassen. Es wird zwar immer noch ein Reverse-Proxy benötigt, aber der Proxy muss den Host:-Header in keiner der Anfragen überprüfen, sodass es schneller geht.

hier ist ein Konfigurationsausschnitt von Pound zu Ihrer Information:

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