Lack -> Nginx -> Apache eine gute Idee?

10

Ich denke über die Architektur eines neuen Webservers nach. Wäre es eine gute Idee, Varnish als Cache vor Nginx als Reverse-Proxy zu haben und statische Dateien vor Apache für alle schweren Aufgaben bereitzustellen?

Ich werde PHP und Ruby auf Schienenanwendungen ausführen.

Wird es zu viel Overhead geben, PHP-Anfragen über zwei andere Prozesse an Apache zu übergeben?

Danke vielmals!

apache-2.2 nginx architecture varnish Zoran Zaric
quelle

Antworten:

8

Ja, es ist gültig. Mein persönlicher Ansatz wäre es, Varnish im Voraus zu verwenden und VCL zu verwenden, um den Datenverkehr zwischen statischen NGINX-Anforderungen und Ihrem schweren Heben aufzuteilen (ob Apache oder Passenger oder ... es spielt keine Rolle). Dies gilt insbesondere dann, wenn es sich auf demselben Computer befindet, auf dem Sie keinen zusätzlichen Overhead benötigen. Es kauft dir nicht unbedingt etwas.

McJeff
quelle
Ja, das ist eine ziemlich gute Idee, da der Lack dafür ziemlich schnell sein sollte
Zoran Zaric
6

Varnish unterstützt (noch) keine gzip-Komprimierung, daher ist es möglicherweise eine Idee, es mit nginx vor sich zu tauschen, um zu komprimieren, was der Lack zurücksendet. Da Lack und Nginx nicht um dieselben Ressourcen kämpfen (Nginx verwendet CPU für die GZIP-Komprimierung, während Lack Speicher verwendet), sollten sie reibungslos auf demselben Computer ausgeführt werden.

Varnish unterstützt jetzt die gzip-Komprimierung . Wenn Sie also keine SSL-Terminierung benötigen (wie in den Kommentaren vorgeschlagen), würde ich empfehlen, den Lack direkt mit dem Internet in Kontakt zu bringen.

Für http:

(Internet) -> (Lack, GZIP, Caching, ESI) -> (Anwendung)

Für https:

(Internet) -> (nginx, ssl) -> (Lack, gzip, Caching, esi) -> (Anwendung)

Wenn Sie dort auch Apache haben möchten (für die allgegenwärtige Unterstützung von mod_foobar), würde ich es zwischen Lack und der Anwendung setzen

Update: Aktualisiert, um die Unterstützung von gzip in Lack 3.0 aufzunehmen. SSl / esi hinzugefügt, wie in den Kommentaren vorgeschlagen

Mogsie
quelle
Wenn der Inhalt, der zum Lackieren bereitgestellt wird, ihn in gzip codiert, gibt der Lack ihn ohne Beanstandung an gzipped weiter: varnish-cache.org/wiki/FAQ/Compression Das einzige, was Lack nicht tut, ist, Inhalte zu entnehmen, die nicht komprimiert sind Anwendung und reservieren Sie es komprimiert. Ist das auch dein Verständnis?
Ewalk
Das einzige Mal, wenn Sie Nginx vor dem Lack ausführen, ist die Verwendung von ESI. Da Sie keine ESI-Assemblierung von komprimierten Seiten durchführen können und Varnish eine zusammengesetzte Seite nicht komprimiert, wird Nginx vor Varnish platziert, um diese Komprimierung bereitzustellen. Wenn der Ursprung dem komprimierten Inhalt dient, gibt Varnish diese Daten in komprimierter Form an den Client weiter.
user6738237482
Ja, ESI ist einer der Gründe, warum ich diese Konfiguration empfehlen würde, aber ich denke, wenn Ihr Backend komprimiert wird und Sie ESI nicht verwenden, können Sie auf Nginx verzichten, da ich glaube, dass Lack viel Verkehr ohne verarbeiten kann in Schweiß ausbrechen.
Mogsie
@ user6738237482, nginx unterstützt SSL-Terminierung, Varnish nicht. Vor etwas wie Lack oder Apache zu stehen, ist genau das, wofür nginx ursprünglich als schneller, leichter Proxy-Server entwickelt wurde.
Rmalayter
4

Der Overhead sollte nicht signifikant sein. Ich gehe davon aus, dass ein Teil des Grundes, warum Sie diese beiden Ebenen haben möchten, in der Skalierbarkeit liegt. In diesem Fall würden Sie im Vergleich zu Apache höchstwahrscheinlich feststellen, dass Lack und Nginx nicht sehr hart arbeiten.

Wenn Sie alle drei Ebenen auf einem Computer haben, sollte die Leistung weniger beeinträchtigt werden, bevor Sie die Kapazität des Servers selbst erreichen.

Als Alternative, warum nicht Lack + Nginx mit Passagier? Ich habe dieses Setup in der Vergangenheit verwendet und Nginx mit Passagier ist relativ leicht und lief ziemlich gut. Es könnte sich lohnen, darüber nachzudenken, wenn Sie nicht mit Apache verheiratet sind, der Ihren Schienenstapel betreibt.

Tony
quelle
Ja, ich könnte für Rails von Apache zu Nginx wechseln, aber Kunden die Möglichkeit zu geben, .htaccess-Dateien zu verwenden, ist ein + für Apache, zumindest für PHP.
Zoran Zaric
2

Ich bin der Systemadministrator für eine Startup-E-Commerce-Plattform. Wir verwenden Lack + Nginx vor unserem PHP / Apache-Stack und es hat Wunder gewirkt.

Wir haben eine Anwendung mit hohem Speicherbedarf und die App verbrauchte ungefähr 15 bis 20 GB RAM pro Webknoten. Sobald wir den Lack vorgelegt haben, sind es jetzt ungefähr 8 GB RAM pro Knoten. Sie haben nie versetzt.

Ich kann es nur empfehlen.

Mike
quelle
3
Sie wissen, Lack spricht nicht ssl richtig?
Mike
1

Ich verwende Drupal mit dem Boost-Modul auf einem Apache + PHP + MySQL-Server, aber vor ihnen verwende ich Nginx mit aktivierter gzip-static-Funktion und verwende die Boost-Ergebnisse, um den Benutzern zu dienen.

Und obendrein verwende ich Lack, alle auf demselben PC, ich habe gute Ergebnisse.

Ich benutze auch Nginx, um die Header zu optimieren, die Drupal für den Cache nicht sehr gut macht.

Go2linux
quelle
0

Es ist keine gute Idee, wenn Sie nicht so etwas wie ESI benötigen. Nginx verfügt über ein eigenes Caching-System, das eine bessere Leistung erbringt .

VBart
quelle
Ich weiß, dass dies eine alte Antwort ist, aber leider ist dieser Link nicht mehr verfügbar, sodass ich Ihren Anspruch nicht überprüfen kann. Nach meiner Erfahrung ist Varnish in seiner Geschwindigkeit und Flexibilität als Reverse-Proxy kaum zu übertreffen.
Martijn Heemels
@MartijnHeemels web.archive.org/web/20130501222206/http://todsul.com/… und es gibt einen weiteren Benchmark: nbonvin.wordpress.com/2011/03/24/…
VBart
-1

Apache kann zum Beenden (Entschlüsseln) von SSL verwendet werden. Überprüfen Sie http://noosfero.org/Development/Varnish#SSL

Brauliobo
quelle
1
Bitte vermeiden Sie es, Links als Antworten zu veröffentlichen, da Ihre Antwort wahrscheinlich jede Bedeutung verliert, wenn sie von linkrot betroffen ist . Bitte überlegen Sie, Ihre Antwort zu bearbeiten und relevante Teile aus dem Link aufzunehmen, den Sie in Ihrer Antwort angegeben haben. Lassen Sie den Link auf jeden Fall als Referenz.
Bryan