Ich habe fälschlicherweise angenommen, dass meine internen AB-Tests bedeuten, dass mein Server 1 KB Parallelität bei 3 KB Treffern pro Sekunde verarbeiten kann.

Meine derzeitige Theorie ist, dass das Netzwerk der Engpass ist. Der Server kann nicht schnell genug genug Daten senden.

Externe Tests von blitz.io bei einer Parallelität von 1 KB zeigen, dass meine Zugriffe auf 180 begrenzt sind, wobei die Seiten immer länger brauchen, um zu antworten, da der Server nur 180 pro Sekunde zurückgeben kann.

Ich habe eine leere Datei von Nginx bereitgestellt und sie gecancelt: Sie skaliert 1: 1 bei gleichzeitiger Verwendung.

Um Engpässe bei IO / Memcached auszuschließen (Nginx zieht normalerweise aus Memcached), stelle ich eine statische Version der zwischengespeicherten Seite aus dem Dateisystem bereit.

Die Ergebnisse sind meinem ursprünglichen Test sehr ähnlich; Ich bin auf ca. 180 RPS begrenzt.

Wenn ich die HTML-Seite in zwei Hälften teile, verdopple ich den RPS-Wert, sodass er definitiv durch die Größe der Seite begrenzt ist.

Wenn ich intern ApacheBench vom lokalen Server aus verwende, erhalte ich konsistente Ergebnisse von etwa 4 KBit / s sowohl auf der ganzen als auch auf der halben Seite bei hohen Übertragungsraten. Übertragungsrate: 62586,14 [KB / s] empfangen

Wenn ich von einem externen Server abweiche, erhalte ich ungefähr 180 RPS - genau wie die Ergebnisse von blitz.io.

Woher weiß ich, dass es keine absichtliche Drosselung ist?

Wenn ich ein Benchmarking von mehreren externen Servern durchführe, werden alle Ergebnisse schlecht, was mich zu der Annahme veranlasst, dass das Problem im ausgehenden Datenverkehr MEINER Server liegt, und nicht in der Download-Geschwindigkeit meiner Benchmarking-Server / blitz.io.

Ich bin also zu dem Schluss gekommen, dass mein Server nicht schnell genug Daten senden kann.

Habe ich recht? Gibt es andere Möglichkeiten, diese Daten zu interpretieren? Ist die Lösung / Optimierung zum Einrichten mehrerer Server + Lastenausgleich, die jeweils 180 Treffer pro Sekunde liefern können?

Ich bin ziemlich neu in der Serveroptimierung, daher würde ich mich über jede Bestätigung freuen, die diese Daten interpretiert.

Ausgehender Verkehr

Weitere Informationen zur ausgehenden Bandbreite finden Sie hier: Das Netzwerkdiagramm zeigt eine maximale Ausgabe von 16 Mb / s: 16 Megabits pro Sekunde. Klingt überhaupt nicht nach viel.

Aufgrund eines Throttling-Vorschlags habe ich mir das angeschaut und festgestellt, dass Linode eine 50-Mbit / s-Obergrenze hat (die ich anscheinend nicht annähernd erreicht habe). Ich hatte es auf 100mbps angehoben.

Bedeutet dies, dass mein Server zwar bis zu 100 MBit / s ausgeben kann, aber durch einen anderen internen Engpass eingeschränkt ist, da Linode meinen Datenverkehr begrenzt und ich ihn nicht einmal erreicht habe? Ich verstehe einfach nicht, wie Netzwerke in dieser Größenordnung funktionieren. Können sie buchstäblich so schnell Daten senden, wie sie von der Festplatte lesen können? Ist die Netzwerkleitung so groß?

Abschließend

1: Auf der Grundlage der obigen Ausführungen denke ich, dass ich meine 180 RPS definitiv steigern kann, indem ich einen Nginx-Load-Balancer auf ein Multi-Nginx-Server-Setup mit genau 180 RPS pro Server hinter dem LB setze.

2: Wenn Linode ein Limit von 50/100 MBit hat, das ich überhaupt nicht einhalte, muss es etwas geben, das ich tun kann, um dieses Limit mit meinem Single-Server-Setup zu erreichen. Wenn ich Daten lokal schnell genug lesen / übertragen kann und es sogar stört, eine 50-MBit / 100-MBit-Obergrenze zu erreichen, muss es einen internen Engpass geben, der es mir nicht ermöglicht, die Obergrenzen zu erreichen, bei denen ich nicht sicher bin, wie ich sie erkennen soll. Richtig?

Mir ist klar, dass die Frage jetzt groß und vage ist, aber ich bin nicht sicher, wie ich sie verdichten soll. Jede Eingabe wird zu jeder Schlussfolgerung, die ich gemacht habe, geschätzt.

Das Problem war, dass ich davon ausgegangen bin, dass die Linode.com-Grafikspitzen wahre Spitzen sind. Es stellte sich heraus, dass die Grafik 5 Minuten Durchschnittsdatenpunkte verwendet, sodass mein Peak 24 MBit zu betragen schien, als ich tatsächlich die 50 MBit-Obergrenze erreichte.

Nachdem sie es auf 100 MBit angehoben haben, stiegen meine Benchmarks sofort auf das neue ausgehende Verkehrslimit.

Wenn ich das nur früher bemerkt hätte! Ein Großteil meiner Überlegungen beruhte auf der Idee, dass ich aufgrund dieses Diagramms kein ausgehendes Verkehrslimit erreicht hatte.

Jetzt habe ich einen Spitzenwert von 370 Anfragen pro Sekunde, was genau unter 100 MBit / s liegt. Zu diesem Zeitpunkt bekomme ich einen "Rückstand" an Anfragen und die Antwortzeiten steigen.

Ich kann jetzt die maximale Parallelität erhöhen, indem ich die Seite verkleinere. mit aktiviertem gzip bekomme ich 600RPS.

Ich habe immer noch Probleme, wenn ich plötzlich einen Spitzenwert erreiche und sich der Rückstand an ausstehenden Anforderungen (begrenzt durch die Bandbreite) zu häufen beginnt, aber das klingt nach einer anderen Frage.

Es war eine großartige Lektion in Bezug auf die Optimierung / das Lesen dieser Daten / das Eingrenzen der möglichen Probleme. Vielen Dank für Ihren Beitrag!

Ein bisschen spät, jetzt, wo Sie es herausgefunden haben ... aber vielleicht sollten Sie das ServerFault-Blog von Zeit zu Zeit lesen.

Ich denke dabei insbesondere an diesen Beitrag , in dem diskutiert wird, warum ein Abrufintervall von einer Sekunde nicht von Zeit zu Zeit verkürzt wird, da es sich um ein sehr ähnliches Problem handelt wie das, das Sie hatten.

Wir haben festgestellt, dass wir Pakete auf 1-Gbit / s-Schnittstellen mit Raten von nur 10-30 MBit / s ziemlich häufig verwerfen, was unsere Leistung beeinträchtigt. Dies liegt daran, dass die Rate von 10-30 MBit / s tatsächlich die Anzahl der pro 5 Minuten übertragenen Bits ist, die in eine 1-Sekunden-Rate umgewandelt wurden. Wenn wir näher an Wireshark herangehen und eine Millisekunden-E / A-Grafik verwenden, sehen wir, dass die 1-Mbit / Millisekunden-Rate der sogenannten 1-Gbit / s-Schnittstellen häufig geplatzt ist.

Sicher hat mich zum Nachdenken gebracht. Und ich weiß nur, dass ich die erste Chance, die ich bekomme, gegen die anderen SAs in meinem Geschäft erreiche. Wenn wir auf dieses Problem stoßen, werden wir unglaublich brillant und einfühlsam aussehen.

Wer weiß, ich darf sogar einige von ihnen insgeheim lassen. :)

Es kann durch das Netzwerk begrenzt sein, ist aber nicht unbedingt nur eine Frage der Bandbreite. Die Latenz Ihres Remote-Testgeräts hat Auswirkungen auf die Anzahl der zu einem bestimmten Zeitpunkt anstehenden Verbindungen (das Warten auf Bestätigungen von 50 ms unterscheidet sich erheblich von 0,5 ms vor Ort) sowie auf die Aushandlung und Stabilisierung der Fenstergröße im Verlauf der Verbindung. Sie sind wahrscheinlich auch einem gewissen Paketverlust ausgesetzt - entweder als eine Funktion der Überlastung oder als ein Mechanismus der Bandbreitenbeschränkung seitens Ihres Betreibers (oder derjenigen, die vorgelagert sind).

Ich würde vorschlagen, so viel wie möglich aus der Gleichung zu streichen, um eine vernünftige Grundlinie zu ziehen. Messen Sie die maximale Bandbreite, Latenz und den Paketverlust von Ihrem Server bis zu einigen Punkten im allgemeinen Internet. Versuchen Sie, so unwahrscheinlich es auch klingen mag, nach "Voip-Verkehrstest" oder ähnlichem zu suchen. Einige Anbieter von VOIP-Diensten verfügen über Apps, die diese Art von Mustern (bidirektional) mit einem angemessenen Maß an Genauigkeit messen können. Sobald Sie einige gültige empirische Daten zur tatsächlichen nützlichen Geschwindigkeit Ihres Links haben, können Ihre Ergebnisse durchaus validiert werden.

Zusätzlich zu den Bandbreitentests kann es auch nützlich sein, eine Paketerfassung des unterdurchschnittlichen Webverkehrs auf übermäßige Anzahl von Neuübertragungen zu überprüfen und die scheinbare Zeit zu messen, die Ihr Server benötigt, um auf Anforderungen zu antworten (..wenn dies zutrifft) Der Wert steigt in Abhängigkeit von der Anzahl der Verbindungen erheblich an. Dies ist ein wichtiger Hinweis.