Für unser Spiel hosten wir die statischen Assets auf einer VM, auf der nur httpd installiert und ausgeführt wird (natürlich neben einigen nativen Linux-Dingen), um Webinhalte bereitzustellen. MPM ist so konfiguriert, dass es mit MaxClients von 6400, ServerLimit 100 und ThreadsPerChild 64 funktioniert. Der Speicher beträgt 4 GB. Mit der obigen Konfiguration hat der bereitgestellte statische Inhalt eine Gesamtgröße von etwa 20 MB und wird in meinem Land (Bulgarien) sowie in verschiedenen anderen Ländern bereitgestellt. Es wurde überprüft und bestätigt, dass sich die nationalen und internationalen Bandbreitengeschwindigkeiten nicht unterscheiden. In Spitzenzeiten, wenn die Bandbreite maximal ausgelastet ist, erhalten wir jedoch Massenbeschwerden von entfernten Benutzern (z. B. aus Russland), dass der vollständige Download des Spiels 2-3 Minuten dauert. Jedes Mal, wenn wir das Laden des Spiels mit deaktiviertem Cache von hier aus überprüft haben, dauerte es bei jedem Versuch von jedem Computer aus etwa 10 Sekunden. Wir haben 2 weitere VMs aus dem Image der ursprünglichen VM hinzugefügt (dieselbe Konfiguration und derselben Inhalte) und das schnellste Lastenausgleichs-DNS-Round-Robin für insgesamt drei IPs durchgeführt. Die Beschwerden nahmen ab, aber die Ladezeit für russische Benutzer betrug weiterhin über 1 Minute. Als wir erneut versuchten, das Spiel mehrmals von hier herunterzuladen, dauerte es immer noch 10 Sekunden, für uns kein Unterschied. Was könnten die möglichen Gründe sein, wenn man bedenkt, dass statische Inhaltsserver über gleiches nationales und internationales Peering verfügen und bei geringer Auslastung alle russischen Benutzer auch 10 Sekunden zum Herunterladen brauchen, aber nicht zu Spitzenzeiten? Sollte das nicht für alle Benutzer gleich sein?
PS: Die statischen Server hatten immer genügend Speicher und die Anzahl der erzeugten HTTPD-Prozesse stieg nie über 50, mit einem festgelegten Limit von 100.
EDIT: Kurze Zusammenfassung der Frage – bei geringer Auslastung laden alle Clients (lokal und entfernt) den Client gleich lange herunter (z. B. 15 Sekunden). Bei hoher Auslastung laden lokale Clients ihn erneut 15 Sekunden lang, während entfernte Clients dies 2-3 Minuten lang tun. Was sind die möglichen Gründe?
Antwort1
Gemäßdie Klarstellung, dass dies nur dann geschah, wenn die Bandbreite ausgeschöpft war, das mag wie ein völlig normales Verhalten klingen, aber wenn Sie Ihre verfügbare Bandbreite (zur Leitungsrate) maximieren, können Sie anfangen, Pakete zu verlieren und habenTCP-Fensterfür langangebundene Kunden, die nie für optimale Geschwindigkeiten hochskaliert wurden;Bandbreitenverzögerungsproduktwächst, erhöht sich die Zeit zum Herunterladen derselben Datei über dieselbe Leitung. Sie müssten einigeVerkehrsformung(mit anderen Worten,Paketwarteschlangen und Priorisierung), wenn Sie es während der Überlastungsphasen für alle gleichmäßiger gestalten möchten. – cnst 6. Okt. um 4:56
Antwort2
Die Antwort hängt von vielen Faktoren ab. Sie können nicht einfach sagen, dass Ihre internationalen Geschwindigkeiten konstant sind. Bei entfernten Benutzern wird die Leistung immer geringer sein, je nachdem, welches Netzwerk zwischen Ihnen und ihnen besteht und wie stark es ausgelastet ist.
Übrigens, Sie haben gesagt, Ihre Bandbreite sei ausgereizt. Bandbreite der Netzwerkverbindung Ihres Servers? Dann brauchen Sie wirklich ein CDN oder zwischenspeichernde Reverse-Proxys.
Ich kann einige schnelle Verbesserungen vorschlagen:
- Verwenden Sie Nginx. Es kann statische Inhalte viel effizienter bereitstellen.
- Verwenden Sie ein CDN wie Cloudflare. Wenn Ihnen das zu aufwendig ist, können Sie auch eine VM in Russland mieten und dort einen Caching-Reverse-Proxy installieren, Ihre DNS-Geo-IP-Adresse angeben und russische Benutzer dorthin umleiten lassen. Cloudflare ist vielleicht sogar einfacher :)
Antwort3
Man kann nicht wirklich sagen, dass Peering für nationalen und internationalen Verkehr dasselbe ist.
Dies mag sich in den letzten Jahren geändert haben, aber traditionell haben die meisten Anbieter in Russland nie für lokales Peering bezahlt, sondern es direkt von MSK-IX bezogen, während der restliche Verkehr von Transitanbietern abgewickelt wurde.
Die Links in die verschiedenen Richtungen haben fast immer unterschiedliche Kapazitäten und sehr häufig sind bestimmte Links hin und wieder überlastet (entweder durch unerwartete Verkehrsspitzen oder weil jemand zu faul ist, seine Links zu aktualisieren oder weil er für mehr Verkehr mehr bezahlt usw.). Dies kann insbesondere während der Stoßzeiten häufiger passieren.
An den Peering- oder Transitpunkten zahlen Anbieter häufig einen Festpreis für unbegrenzte 100 Mbit/s, 1 Gbit/s oder 10 Gbit/s. Was passiert, wenn der Datenverkehr den bezahlten Betrag übersteigt? Einige Pakete gehen verloren, andere werden verlangsamt, und das passiert im Allgemeinen nur während der Spitzenzeiten und manchmal nur in eine Richtung (aber selbst wenn es in eine Richtung passiert, wird der Datenverkehr in beiden Richtungen verlangsamt, da die Latenzzeit zunimmt und ACKauch einige Pakete zur Überlastungskontrolle verloren gehen).
Ich würde das Problem beheben, indem ichmtrzu einem der Hosts in Russland, bei dem das Problem auftritt, sowie von einem der Hosts in Russland zu Ihrem Server in Bulgarien. Ich finde es am nützlichsten, jede Instanz 30 Sekunden bis 15 Minuten lang laufen zu lassen (mtr aggregiert die Statistiken für die gesamte Dauer eines solchen Laufs) und sie dann unmittelbar nach Abschluss des vorherigen Laufs noch einmal für weitere 5 bis 15 Minuten laufen zu lassen. Auf diese Weise können Sie genau sehen, während welcher Zeit die Probleme auftreten.
Andernfalls könnte es auch ein Problem mit Apache sein, das möglicherweise mit einer höheren Latenz der Hosts in Russland zusammenhängt – nginx ist im Allgemeinen bei der Bereitstellung aller Arten von Inhalten effizienter als Apache, also ist dies vielleicht eine gute Gelegenheit, stattdessen nginx auszuprobieren?
Antwort4
Während die Lichtgeschwindigkeit konstant ist und Daten über Glasfaserkabel mit großer Entfernung mit der gleichen Geschwindigkeit übertragen werden, müssen sie umso mehr „Sprünge“ durchlaufen, je weiter sie von der Quelle entfernt sind.
Wenn Sie einen Traceroute zu einem 100 Meilen entfernten Server ausführen und diesen Traceroute dann mit einem Server vergleichen, der sich am anderen Ende der Welt befindet, wird der Server am anderen Ende der Welt wahrscheinlich viel mehr Hops durchlaufen.
Latenzist die Zeit, die Daten benötigen, um jeden Router (Hop) auf dem Weg zu ihrem Ziel zu durchlaufen. Das Problem hierbei ist die Latenz.