Warum ist Nginx so schnell?

31

Wie kann eine Site wie Rambler so schnell dynamische Inhalte bereitstellen? Noch schneller als Yahoo (der einen Server in meinem Land hat - Südostasien; Rambler nicht).

Ist das nur die Fähigkeit von Nginx? Wo sollte ich nachsehen, um mehr über solche Fähigkeiten zu erfahren?

Ich glaube, dass serverfault.com, wenn es von Nginx bereitgestellt wird, viel schneller ist als IIS 7 (vorausgesetzt, die Zugriffszeit für db ist in beiden Fällen gleich). Ist das eine faire Annahme?

Bearbeiten:

Post von Karl mit Nginx vor IIS7

Quintin Par
quelle
Beachten Sie, dass serverfault.com bereits Nginx verwendet (laut Wappalyzer ). : P
WillS

Antworten:

26

Sie können diese Präsentation für eine Übersicht der Nginx-Interna sehen. Der Hauptunterschied ist die asynchrone Verarbeitung von Anforderungen, anstatt Threads wie bei Apache zu verwenden. Sie können sich auch diese Dokumentation ansehen .

Maxwell
quelle
2
Gute Antwort auf die Architektur von Nginx und das C10K-Problem. Ich verstehe OPs Frage jedoch als eine Frage der wahrgenommenen Seitenladegeschwindigkeit, die wenig mit Nginx zu tun hat.
Jesper M
Was bedeutet eigentlich "asynchron"? Ich habe immer gedacht, dass es bedeutet, in einem separaten Thread ausgeführt.
Ivan
Asynchroner Mittelwert Nginx fungiert immer als Proxy, auch mit PHP: Nginx erhält die HTTP-Anfrage, sendet sie an den PHP-Server, ABER es wird nicht gesperrt / gewartet, um die HTTP-Antwort zu senden. Aus diesem Grund sehen Sie einen Unterschied (Geschwindigkeit, CPU / RAM) bei stark frequentierten Websites. Für einige Anfragen (die 95% des Internets betreffen ...) gibt es keinen Leistungsgewinn, aber Nginx ist cool ;-)
Thomas Decaux
21

Wie kann eine Site wie Rambler so schnell dynamische Inhalte bereitstellen? ... Ist das nur die Fähigkeit von Nginx? Wo sollte ich nachsehen, um mehr über solche Fähigkeiten zu erfahren?

Dies hat wenig bis gar nichts mit dem verwendeten Webserver zu tun - sowohl Nginx als auch IIS und Apache sind "schnell genug" und erledigen ihre Arbeit im Allgemeinen innerhalb von Millisekunden. nginx ist viel schneller als Apache, dies bedeutet jedoch lediglich, dass der Websitebesitzer weniger Server für den Web-Serving-Part benötigt - nginx überträgt keine Daten schneller an Sie.

Der weniger wichtige Teil ist die serverseitige Geschwindigkeit , dh die Zeit, die zum Erstellen des HTML-Codes benötigt wird. Der wichtigere Teil ist die "Frontend" -Performance , mit der ich HTML, CSS, Javascript und Bilder, deren Anzahl, deren Größe und die ordnungsgemäße Bereitstellung (HTTP-Komprimierung, Caching) meine.

Natürlich ist die serverseitige Geschwindigkeit immer noch wichtig, ich sage nicht, dass sie ignoriert werden sollte oder dass es keine Rolle spielt. In der Regel ist dies jedoch der kleinste Teil der Geschwindigkeit, die vom Endbenutzer wahrgenommen wird. Die serverseitige Arbeit dauert häufig weniger als 500 Millisekunden, aber die Seite ist erst nach 3.000 bis 5.000 Millisekunden fertig. Der Großteil dieser Zeit entfällt auf das Herunterladen der Frontend-Ressourcen (CSS, Javascript, Bilder).

Steve Souders hat die ursprüngliche Arbeit bei Yahoo erledigt und arbeitet jetzt bei Google. Sein erstes Buch "High Performance Websites" ist der beste Ausgangspunkt, um mehr über das Erstellen schneller Websites zu lernen. Dasselbe Material wie in seinem Buch finden Sie in diesem Videogespräch und in diesen Gestaltungsregeln . Ich finde jedoch, dass das Buch schnell zu lesen und viel einfacher zu verstehen ist.

Sie können die Websites über den Tester von WebPageTest.org ausführen. Dadurch erhalten Sie ein gutes Gefühl für den Frontend-Teil dieser Websites und dafür, warum sie schneller oder langsamer sind.

Ich glaube, dass serverfault.com, wenn es von Nginx bereitgestellt wird, mit IIS 7 viel schneller ist (vorausgesetzt, die Zugriffszeit für db ist in beiden Fällen gleich). Ist das eine faire Annahme?

Nein, das ist ein Missverständnis. :-)

Jesper M
quelle
18

Nginx wird häufiger zum Lastenausgleich für andere Anwendungen / Server und zum Bereitstellen statischer Inhalte verwendet als als vollständiger Server.

Beispielsweise können Sie eine App mit einem der vielen Python-Frameworks schreiben und Nginx als Front-End für viele Instanzen verwenden (möglicherweise über mehrere Computer verteilt). In diesem Fall dient nginx zwei Zwecken: Es verarbeitet Anforderungen für statischen Inhalt wie Bilder und Stylesheets direkt (und aufgrund seines Designs geschieht dies sehr schnell) und leitet dynamische Anforderungen an die Anwendung weiter, die die Last auf alle ihm bekannten Instanzen verteilen . Dies ist auch in der Ruby on Rails-Community eine sehr beliebte Konfiguration.

Es gibt zwei weitere mögliche Gründe, warum Rambler für Sie schneller erscheint als der lokale Yahoo-Dienst. Erstens verfügt der lokale Yahoo PoP möglicherweise nicht über genügend Ressourcen, um die Anzahl der Anfragen zu bedienen, die schneller eingehen. Wenn Sie also einfach mehr Hardware hinzufügen (vorausgesetzt, die Software lässt sich auf diese Weise gut skalieren), wird dies möglicherweise beschleunigt (aber der Unterschied ist vermutlich nicht der Fall) lohnt sich die Kosten für die Wartung des zusätzlichen Kits oder Yahoo hätte dies getan). Der andere große Unterschied liegt möglicherweise im Back-End und nicht im Webserver - die beiden Dienste haben zweifellos sehr unterschiedliche Datenbankanordnungen, und selbst wenn dies nicht der Fall ist, werden wahrscheinlich nicht genau die gleiche Anzahl von Abfragen (und die Anzahl von Abfragen) ausgeführt Hardware, die der Datenbankarchitektur gewidmet ist, wird ebenfalls erhebliche Auswirkungen haben.

Die Analyse, warum ein Dienst schneller ist als der andere (im Allgemeinen oder unter bestimmten Umständen), führt in der Regel nicht zu einer einfachen Antwort. Es gibt viele Möglichkeiten, eine App zu entwerfen, die auf viele Tausende von Benutzern mit jeweils einer Antwort skaliert werden kann Eigene Vorteile, Probleme und Kompromisse, und selbst wenn Sie all diese Unterschiede herausrechnen, hat jede Site eine andere Dynamik für die Nutzerbasis. Außerdem gibt es Netzwerkprobleme, die sich auch der Kontrolle der Designer entziehen.

David Spillett
quelle
3

nginx möglicherweise aber skalierbarere architektur mit angemessenem lastausgleich vor statischen inhaltsservern / dynamischen inhaltsgeneratoren. Wenn Sie wirklich eine großartige Endbenutzererfahrung erzielen möchten, sollten Sie den Inhalt wahrscheinlich näher an die "Augäpfel" heranrücken - verwenden Sie eine CDN.

Wenn Sie sich für das Thema interessieren - schauen Sie sich dies und das an und ... also - google; -]

pQd
quelle
2

Die besten Sites verwenden Anwendungsbeschleuniger wie die ZXTMs von Zeus - sie können in vielen Fällen dynamische Antworten zwischenspeichern, was offensichtlich von großem Vorteil ist.

Chopper3
quelle
0

Es fällt mir schwer, einen Serverfehler viel schneller zu erkennen (SO könnte es möglicherweise zu Problemen beim Laden aufgrund des Datenverkehrs kommen?), Da hier in der EU bereits eine Seite über meine Route geladen wird. Es ist viel schneller und reaktionsschneller als die meisten lokalen Nachrichtenseiten und so weiter.

Die meisten offensichtlichen Probleme mit Ladezeiten und Latenzzeiten entstehen zwischen dem Server und dem Endbenutzer und nicht durch die tatsächliche Serverleistung (es sei denn, jemand hat die Größe oder das Design falsch eingestellt). Verschiedene Sites können auf unterschiedliche Weise geroutet werden, und es besteht die große Wahrscheinlichkeit, dass eine länderbezogene Site für mich eine größere Latenz aufweist als irgendetwas auf der Welt - alles hängt von so vielen Variablen ab, dass man nicht sagen kann, dass sie nur durch einen Service lösbar ist Upgrade / Switch, es sei denn, Sie wissen, dass hier das Problem für eine bestimmte Verwendung (r) liegt ...

Offensichtlich macht das Zwischenspeichern verschiedener Arten auf dem Server einen großen Unterschied, aber soweit ich weiß, tun dies alle diese Sites bereits.

Oskar Duveborn
quelle