Nginx vs Apache als Reverse Proxy, den man wählen kann


36

Diese Art von Frage wurde hier vielleicht gestellt, aber ich konnte keine finden, die wirklich zu meiner Frage passt. Ich habe gehört, dass die Leistung von Nginx ziemlich beeindruckend ist, aber Apache verfügt über mehr Dokumente und eine Community (lesen: Experte), um Hilfe zu erhalten

Jetzt möchte ich wissen, wie sich beide Webserver in Bezug auf Leistung, Einfachheit der Konfiguration, Anpassungsgrad usw. ALS REVERSE PROXY-Server in einer vps-Umgebung?

Ich wiege immer noch zwischen den beiden für eine Ruby-Web-App (nicht ROR), die mit Thin (einer von Ruby-Webservern) bedient wird.
Spezifische Antwort wird sehr geschätzt. Die allgemeine Antwort, den Rubin-Teil nicht zu berühren, ist in Ordnung. Ich bin immer noch kein Neuling in der Webserververwaltung.


danke an martin und webdestroya, jetzt neige ich mich zu nginx
mhd

Wäre es nicht sinnvoller, einen speziell entwickelten Reverse-Proxy-Lack zu verwenden?
ptman

Antworten:


31

Ich wollte dies in einen Kommentar einfügen, da ich mit dem wichtigsten Punkt der Antwort von webdestroyas einverstanden bin, aber es wurde ein bisschen zu lang.

Sie befinden sich in einer VPS-Umgebung. Dies bedeutet, dass Sie höchstwahrscheinlich wenig RAM haben. Schon aus diesem Grund sollten Sie Nginx verwenden, da sein Speicherbedarf geringer ist als der von Apaches.

Auch stimme ich einigen der genannten Argumente nicht zu.

Einfache Konfiguration:
Nginx ist nicht schwieriger als Apache. Es ist anders. Wenn Sie an Apache gewöhnt sind, werden Änderungen immer schwieriger. Dies bedeutet nicht, dass der Konfigurationsstil selbst schwieriger ist. Ich bin vor über einem Jahr vollständig von Apache auf Nginx umgestiegen, und heute habe ich Probleme, einen Apache-Server zu konfigurieren, während ich finde, dass Nginx extrem einfach zu konfigurieren ist.

Für Ruby:
Nginx hat Passenger, jedoch sehe ich es normalerweise als die schlechtere Methode an, um eine Verbindung zu Ruby herzustellen. Ich bin kein Ruby-Programmierer, daher kann ich das nicht überprüfen, aber ich sehe Unicorn und Thin oft als bessere Alternativen.

Fazit:
Nginx wurde als Reverse-Proxy eingerichtet. Zunächst wurden lediglich statische Dateien bereitgestellt und ein Reverse-Proxy über HTTP / 1.0 an einen Back-End-Server gesendet. Seitdem wurden FastCGI, Load Balancing und verschiedene andere Funktionen hinzugefügt. Der ursprüngliche Entwurfszweck bestand jedoch darin, statische Dateien und Reverse Proxy bereitzustellen. Und das macht es wirklich gut.

Apache ist im Gegenteil ein Allzweck-Webserver. Ich bezweifle nicht, dass es Proxy einwandfrei rückgängig machen kann, aber es wurde nicht für einen minimalen Speicherbedarf entwickelt und erfordert daher mehr Ressourcen als Nginx, was bedeutet, dass mein anfängliches VPS-Umgebungsargument ins Spiel kommt.


+1 zur Verdeutlichung.
John Gardeniers

Ich würde so weit gehen, es als Ihren einzigen Webserver zu empfehlen. Siehe meine Kommentare serverfault.com/questions/133481/… <- hier. Ich verwende es als einzigen Webserver auf meinem VPS und habe die anderen Benutzer mit FastCGI für ihre PHP / CGI-Apps an Bord geholt.
Jason

Jason Ich verwende es seit über einem Jahr als meinen einzigen Webserver und es verarbeitet täglich Millionen von Seitenladevorgängen. Ich stimme Ihrer Empfehlung voll und ganz zu! :)
Martin Fjordvald

8

Leistung:
NGinX. Dieser Server ist als einer der leistungsstärksten Webserver bekannt und wird von vielen verschiedenen Unternehmen verwendet (Notable, MediaTemple).

Einfache Konfiguration:
Apache. Die Konfiguration von Apache ist sehr einfach und sehr leistungsfähig. Nginx ist mächtig, kann aber sehr schwer zu verstehen sein, da es eher einer Programmiersprache als einer Konfigurationsdatei ähnelt.

Anpassungsgrad:
Apache. Apache hat jede Menge Mods und andere Plugins dafür geschrieben. Nginx hat zwar noch Plugins dafür, aber ich denke, dass Apache viel, viel mehr hat als Nginx.

Für Ruby:
Ich weiß, dass Nginx mit Mongrel / webrick als leistungsstarker Load Balancer eingesetzt werden kann. Apache hat jedoch Phusion / Passenger, was die Integration schöner macht.

Reverse Proxy Gewinner:
NGinX


2
Ich bin interessiert, nicht streiten. Warum ist Nginx ein Gewinner für Reverse Proxy? Der Rest Ihrer Antwort hebt das eine nicht wirklich vom anderen ab. Wenn überhaupt, dann bevorzugt es Apache.
John Gardeniers

1
Nun, zum größten Teil möchten Sie einen Reverse-Proxy aufgrund der hohen Auslastung. Was bedeuten würde, dass Leistung wahrscheinlich das größte Problem ist. In diesem Fall war Nginx der Gewinner, weshalb ich ihn ausgewählt habe. Als Entwickler liebe ich Apache, aber von einem Punkt "Wie kann ich die meiste Leistung von diesem Webserver bekommen" aus würde ich mit Nginx
Mitch Dempsey

8

Nginx ist ereignisbasiert, während Apache prozessbasiert ist. Unter hoher Last macht dies den Unterschied in der Welt aus ... Apache muss für jede Verbindung einen neuen Thread forken oder starten, nginx dagegen nicht. Dieser Unterschied zeigt sich hauptsächlich in der Speichernutzung, aber auch in der Benutzerantwortzeit und anderen Leistungsmetriken. Nginx kann Zehntausende gleichzeitiger HTTP-Keepalive-Verbindungen auf moderner Hardware verarbeiten. Apache verwendet 1 bis 2 MB Stack für jede Verbindung. Wenn Sie also rechnen, können Sie nur ein paar Hundert oder vielleicht tausend Verbindungen gleichzeitig verarbeiten, ohne zu tauschen.

Wir verwenden Nginx vor Apache und IIS in unserer Umgebung als Lastausgleichs- und Caching-Proxy und können nicht zufriedener sein. Wir verwenden zwei kleine Nginx-Boxen anstelle eines Paares sehr teurer geleaster F5-Geräte, und unsere Standorte sind sowohl in Bezug auf die Haptik als auch auf die gemessenen Reaktionszeiten weitaus schneller.


1

Ich war vor ungefähr zwei Wochen in demselben Dilemma wie Sie.

Um Ihnen eine wirklich knappe Antwort zu geben: Meiner Recherche nach ist nginx sehr schnell und ressourcenschonend, wurde jedoch nur für das Umkehren von statischen Proxy-Dateien entwickelt. Der Rest sind aufgeschraubte Lösungen, die Sie konfigurieren oder nach Ihren Wünschen erstellen müssen.

AFAIK nginx hat keine htaccess-Dateien. Sie müssen sich also zurechtfinden, wenn Sie von dieser Funktion abhängig sind.

AFAIK hat alles funktioniert und ich habe Tutorials gesehen.

Ich werde mit Nginx mit meinem Test- und Profiling-Setup gehen. Ich habe eine typische LAMP-Anwendung.

Ich habe gelesen, dass es Leute gibt, die Proxy umkehren und statische Dateien von nginx bereitstellen und alles andere wie PHP an eine laufende Apache-Instanz übergeben. Sie behaupten einen guten Kompromiss. Ich habe keine Leistungsdaten darüber, aber Sie möchten vielleicht wissen.


2
Das Deaktivieren von htaccess-Überschreibungen auf Apache aus Leistungsgründen ist ziemlich verbreitet. Eine solche Funktion auf einem für hohe Leistung ausgelegten Server zu unterstützen, wäre wenig sinnvoll.
theotherreceive

Vielen Dank, dass Sie diese Aussage hinzugefügt haben. Das OP ist kein Profi-Administrator, daher müssen wir uns klar sein.
deploymonkey

1

Ich hatte in den letzten Jahren ernsthafte Probleme mit Apaches mod_proxy auf einer Vielzahl von Plattformen in verschiedenen Umgebungen. Von Zeit zu Zeit funktioniert es einfach nicht mehr und die einzige Möglichkeit scheint darin zu bestehen, den Apache-Server neu zu starten.

Persönlich würde ich nicht "nginx vs Apache" fragen, sondern "nginx vs lighttpd" - und das ist ein weitaus härterer Anruf!


Gültiges Argument, aber als ich das letzte Mal nachgesehen habe, hatte lighttpd noch lange offene Fehler und wurde für Speicherlecks bekannt. Von einem produktiven Einsatz durch Administratoren wurde abgeraten. Hat sich das geändert?
Deploymonkey

Es hat Vorbehalte, sicher (besonders dort , wo sehr große Dateien dient), aber es ist deutlich stabiler als Apache als Proxy - ich habe in mehreren Einsätzen in den letzten sechs Monaten keine wirklichen Probleme hatte
Mo.

Ich habe lighttpd aus irgendeinem Grund von der Kandidatenliste gestrichen :)
mhd
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.