Wir bauen und betreiben China-Auslieferungsinfrastruktur, also brauchten wir unsere eigenen Messungen statt der von jemand anderem. Einen Headless-Browser in Shanghai aufzustellen, dauerte einen Nachmittag. Zahlen zu bekommen, die wir zu veröffentlichen bereit waren, dauerte erheblich länger – weil das meiste, was eine Performance-Messung über Netzwerke annimmt, an der chinesischen Grenze aufhört, wahr zu sein, und zwar nicht auf die offensichtliche Weise. Jeder erwartet höhere Latenz. Fast niemand erwartet, dass die Fehler-Arithmetik unter seinem Werkzeug stillschweigend aufhört zu funktionieren.
Dies ist die Liste dessen, was schiefging. Wir veröffentlichen die Fehler statt der Korrekturen, aus einem Grund, auf den wir am Ende zurückkommen.
Hier ist zuerst die ganze Liste, damit Sie ihre Form sehen. Die rechte Spalte ist der Teil, der zählt: Fast jeder dieser Fehler schob das Ergebnis in die Richtung, die wir bevorzugt hätten.
| # | Was wir falsch gemacht haben | In welche Richtung der Fehler das Ergebnis verschob |
|---|---|---|
| 1 | Vom Browser abgebrochene Anfragen als Netzwerkfehler zählen | Gegen uns |
| 2 | Anfragen, die überhaupt nie beantwortet wurden, nicht zählen | Zu unseren Gunsten |
| 3 | Annehmen, die Fehler seien voneinander unabhängig | Zu unseren Gunsten |
| 4 | Ein Deploy, das einen Container eine Fehlerseite ausliefern ließ | Zu unseren Gunsten |
| 5 | Der IP-Geolokalisierung für die Rechenzentrumsposition vertrauen | Neutral, aber fatal für die Glaubwürdigkeit |
| 6 | Die Probe ins selbe Netzwerk wie einen Endpunkt setzen | Zu unseren Gunsten |
| 7 | „Erreichbar“ so behandeln, als bedeute es „nutzbar“ | Zu unseren Gunsten |
| 8 | Schlüsse aus Einzelstichproben ziehen | Unvorhersehbar |
1. Abgebrochene Anfragen sind keine fehlgeschlagenen Anfragen
Was geschah. Unsere Ressourcenbuchhaltung zählte jede Anfrage, die der Browser nicht abschloss, als Fehler. Eine der ersten Sites, die wir maßen, lieferte eine vollständige Seite in 0,4 Sekunden – und eine Ressourcenverlustrate von 100 %.
Warum es falsch war. net::ERR_ABORTED bedeutet, dass der Browser die Anfrage abgebrochen hat: Eine Navigation ersetzte die Seite, ein Preload blieb ungenutzt, ein Redirect feuerte. Es ist überhaupt kein Netzwerkereignis. Ebenso wenig ERR_BLOCKED_BY_ORB, was eine Browser-Sicherheitsrichtlinie ist. Sie mit echten Netzwerkfehlern zusammenzuwerfen, bläht jede Verlustzahl auf, die Sie veröffentlichen.
Warum es leicht zu übersehen ist. Nichts bricht mit einem Fehler ab. Sie bekommen eine Zahl, die Zahl ist für China plausibel, und der Bestätigungsfehler erledigt den Rest. Wir haben es nur entdeckt, weil 0,4 Sekunden und 100 % Verlust nicht beide wahr sein können.
In welche Richtung es irrt. Gegen uns – dieser ließ das Internet schlechter aussehen, als es ist. Es ist der einzige der acht, der das tat.
2. Die Mauer verwirft meist Pakete. Sie weist sie nicht ab.
Was geschah. Nach dem Beheben von (1) las sich unsere Zählung unerreichbarer Drittanbieter-Hosts als null – während derselbe Seitenaufbau zeigte, dass das eingebettete Video und das Verifizierungs-Widget des Formulars beide fehlschlugen.
Warum es falsch war. Eine blockierte Anfrage erzeugt häufig überhaupt kein Ereignis. Kein Connection Reset, kein Timeout-Fehler, kein loadingFailed. Die Anfrage wird einfach abgesetzt und nie beantwortet. Alles, was Fehlerereignisse zählt – einschließlich der Fehlerzähler in den Browser-Devtools –, wird melden, dass nichts blockiert wurde.
Warum es leicht zu übersehen ist. Dies ist der mit Abstand wichtigste Unterschied zwischen dem Messen Chinas und dem Messen irgendwo sonst, und er ist unsichtbar, wenn Sie je nur Netzwerke gemessen haben, die laut scheitern. In einem gewöhnlichen Netzwerk sagt ein Host, der Sie nicht bedienen kann, das auch.
In welche Richtung es irrt. Zu unseren Gunsten – es lässt die nicht optimierte Baseline weit gesünder aussehen, als sie ist.
3. Das Beheben von (1) ist, was (2) sichtbar machte
Dies sind keine acht unabhängigen Punkte auf einer Checkliste. Das Korrigieren der Fehlerklassifizierung ist, was das Problem des stillen Scheiterns zutage förderte, denn bis das Rauschen der abgebrochenen Anfragen entfernt war, versteckte sich die Null in aller Deutlichkeit.
Dieses Muster wiederholte sich. Mehrere der Fehler unten wurden erst sichtbar, nachdem ein früherer behoben war, und einer von ihnen verbirgt aktiv einen anderen. Das ist die tatsächliche Form dieser Arbeit: keine Liste von Fallstricken, die man an einem Nachmittag abarbeiten kann, sondern ein Satz interagierender Fehlermodi, bei denen die Reihenfolge, in der man sie findet, meist Glück ist.
4. Ein gelöschtes Verzeichnis, das weiter auslieferte
Was geschah. Ein Redeploy erzeugte ein wunderschönes Ergebnis: Zwei unserer drei Auslieferungspfade schlossen den Ladevorgang plötzlich in etwa 200 Millisekunden ab, während der dritte immer noch das Timeout erreichte.
Warum es falsch war. Sie lieferten eine 153-Byte-Fehlerseite. Das Deploy-Skript entfernte und erstellte ein Verzeichnis neu, das ein laufender Container eingehängt hatte; der Container zeigte weiter auf das gelöschte Original und lieferte nichts. Der „Seitenaufbau“ von 200 Millisekunden war ein Fehlerdokument.
Warum es leicht zu übersehen ist. Die Messung schloss erfolgreich ab. Die Statuscodes waren auf der Ebene, die wir prüften, in Ordnung. Sie erzeugte genau das Ergebnis, auf das wir gehofft hatten, was genau der Moment ist, in dem Sie am misstrauischsten sein sollten. Wir entdeckten es, weil eine Seite mit einem eingebetteten Video nicht in 200 Millisekunden laden kann, nirgends, niemals.
In welche Richtung es irrt. Zu unseren Gunsten, dramatisch. Dieser wäre eine veröffentlichte Lüge gewesen.
5. IP-Geolokalisierung ist nicht, wo das Rechenzentrum ist
Was geschah. Drei unabhängige IP-Geolokalisierungsdienste waren sich einig, dass unser Probe-Ziel in Peking war. Die eigenen Instanz-Metadaten des Cloud-Anbieters sagten, es sei in Zhangjiakou – eine andere Stadt, rund 200 km entfernt, in einer anderen Provinz.
Warum es wichtig ist. Jede Zahl, die Sie veröffentlichen, trägt ihre Messposition. „Gemessen aus Peking“ ist eine Tatsachenbehauptung, und wenn ein Leser sie gegen die maßgebliche Quelle prüft und sie falsch ist, ist nun alles andere, was Sie geschrieben haben, ebenfalls verdächtig.
In welche Richtung es irrt. Neutral, aber fatal für die Glaubwürdigkeit.
6. Von wo Sie messen, entscheidet, wer gewinnt
Was geschah. Wir verglichen einen Nearshore-Auslieferungspfad mit einem landesinternen. Gemessen von einem neutralen Drittanbieter-Netzwerk aus war der landesinterne Pfad beim Time-to-First-Byte um das 1,19-Fache schneller. Gemessen von einer Probe, die beim selben Cloud-Anbieter wie das landesinterne Ziel saß, kam derselbe Vergleich auf das 2,82-Fache heraus.
Warum es falsch war. Verkehr zwischen zwei Maschinen im Netzwerk eines Anbieters reitet auf dem internen Backbone dieses Anbieters und berührt nie das öffentliche chinesische Internet, das tatsächliche Nutzer durchqueren. Beide Endpunkte unseres Vergleichs waren zufällig beim selben Anbieter, sodass eine Probe bei diesem Anbieter der einen Seite einen Heimvorteil verschaffte und die andere gleichzeitig benachteiligte.
Warum es leicht zu übersehen ist. Nichts an der Probe sieht falsch aus. Sie ist im richtigen Land, auf einem echten Netzwerk, liefert stabile Zahlen. Die Verzerrung lebt ganz im Routing.
In welche Richtung es irrt. Zu unseren Gunsten – es hat unseren eigenen Schlagzeilen-Differenzierer mehr als verdoppelt.
7. „Erreichbar“ und „schnell“ sind verschiedene Fragen
Was geschah. Wir testeten, ob verschiedene Drittanbieter-Hosts von innerhalb Chinas erreichbar waren, indem wir sie anforderten und den Statuscode prüften. Mehrere kamen in etwa 100 Millisekunden zurück, und wir verzeichneten sie als verfügbar.
Warum es falsch war. Das waren winzige Antworten. Als wir ein echtes Asset von einem derselben Hosts anforderten, kam es mit 14,9 KB/s an – eine Durchsatzzahl rund drei Größenordnungen unter dem, was die Erreichbarkeitsprüfung implizierte. Der Host antwortet. Er liefert nur nicht.
Warum es leicht zu übersehen ist. Jedes Erreichbarkeits-Tool, auch unseres, meldet einen Binärwert. Der Binärwert war korrekt. Er war auch nutzlos.
In welche Richtung es irrt. Zu unseren Gunsten – der nicht optimierte Pfad sieht funktional aus, wenn er es nicht ist.
8. Eine einzelne Messung ist keine Messung
Was geschah. Wir maßen dasselbe Asset über denselben Pfad zweimal, zehn Minuten auseinander. Erste Stichprobe: 449 ms bis zum ersten Byte, 5,5 MB/s. Zweite Stichprobe: 3.135 ms bis zum ersten Byte, 43 KB/s. Dieselbe Datei, dieselbe Route, dieselbe Probe, derselbe Nachmittag.
Warum es falsch war. Der grenzüberschreitende Durchsatz in China variiert über den Tag hinweg um mehr als zwei Größenordnungen. Praktiker werden Ihnen sagen, dass der Abend die Zeit ist, in der sich die Dinge verschlechtern – zeitweise erreichbar, dann langsam. Jede Einzelstichproben-Zahl ist ein Artefakt des Moments, in dem sie genommen wurde, und einen Tagesdurchschnitt zu berichten, löscht genau das Muster, das für jeden, der dort eine Site betreibt, am wichtigsten ist.
In welche Richtung es irrt. In welche Richtung auch immer Sie zufällig gesampelt haben. Das ist das Problem.
Worum es bei dieser Liste eigentlich geht
Sieben dieser acht Fehler ließen unser eigenes Auslieferungsprodukt besser aussehen, als es ist. Wir haben sie behoben, weil eine Messung, die einem schmeichelt, weniger wert ist als gar keine Messung – das erste Beschaffungsteam, das fragt „wie gemessen?“, wird finden, was wir fanden, und alles andere, was wir veröffentlicht haben, geht damit.
Aber es gibt einen zweiten Grund, die Liste statt der Korrekturen zu veröffentlichen.
Keiner davon ist exotisch. Jeder ist die Art Sache, die man findet, indem man dieselbe Messung oft genug, unter genug Bedingungen laufen lässt, dass die Widersprüche anfangen aufzutauchen: eine Seite, die in 0,4 Sekunden lädt und 100 % ihrer Ressourcen verliert; null blockierte Hosts auf einer Seite, deren Video nicht abspielt; ein 200-Millisekunden-Ladevorgang einer Seite mit eingebettetem Video. Die Fehler kündigen sich nur an, wenn Sie bereits wissen, wie die Zahlen aussehen sollten.
Dieses Wissen ist keine Technik. Es ist der Rückstand davon, es wiederholt falsch gemacht zu haben, weshalb wir die Fehlermodi präzise beschreiben können und weshalb ein erster Versuch die meisten davon dennoch in einer anderen Reihenfolge treffen wird.
Wenn Sie Ihre eigene Site von innerhalb Chinas messen, ist das Nützlichste auf dieser Seite Punkt 2: Prüfen Sie, ob Ihr Werkzeug Anfragen zählt, die überhaupt nie beantwortet wurden, als etwas anderes als Anfragen, die fehlschlugen. Die meisten Werkzeuge tun das nicht, und der Unterschied zwischen diesen beiden Zahlen ist üblicherweise die ganze Geschichte.
Was wir als Nächstes messen
Ein 24-Stunden-Sampling-Lauf über fünf Drittanbieter-Ressourcenkategorien, direkt gegen durch-unser-Netzwerk-ausgeliefert, aufgeschlüsselt nach Stunde der chinesischen Ortszeit statt gemittelt – speziell um die in Punkt 8 beschriebene abendliche Verschlechterung zu charakterisieren. Danach dieselbe Referenzseite, gemessen von einer chinesischen Büro-Breitbandleitung statt einem Rechenzentrum, weil der internationale Transit eines Rechenzentrums wesentlich besser ist als das, was ein echter Nutzer hat, und jede Zahl, die wir bisher veröffentlicht haben, daher eine Untergrenze statt eines Worst Case ist.
Beide Ergebnisse werden hier veröffentlicht, einschließlich der Teile, die nicht für uns sprechen.
Wenn Sie sehen wollen, was Ihre eigene Site von innerhalb Festlandchinas gerade tut, laufen unser China-Firewall-Test und China-Speed-Test beide von Proben innerhalb des Festlands. Und wenn Sie sich fragen, ob von innerhalb Chinas ausgeliefert zu werden selbst die Lösung ist, haben wir auch das gemessen: ist es nicht.