Safe Network Entwickler Update 🇩🇪 1. September 2022

Dies ist eine maschinelle Ăśbersetzung. Das Original in Englisch ist hier: Update 01 September, 2022

In einer rundum guten Woche zum Aufspüren nerviger Anomalien und Fehler bitten wir @joshuef zu erklären, wie wir Probleme aufgrund der Nachrichtenserialisierung und der Belastung des Netzwerks angehen. So etwas wie eine :bulb: diese hier …

Allgemeiner Fortschritt

@davidrusu hat ein Problem behoben, bei dem Erwachsene Anti-Entropie-Prüfungen übersprangen vor Splits, sodass sie nicht immer die nötigen Up-to- Datumsinformationen zu den Abschnitten.

In der Zwischenzeit arbeitet @bochaco an einer Liste von Verbesserungen in Bezug auf wie wir Register speichern (änderbare Daten – CRDTs), einschließlich der Änderung einiger interner Speicher-APIs um das Klonen einiger Objekte zu vermeiden, einzelne Operationen zu schreiben (statt als eine Datei, die durch eine andere unvollständige CRDT überschrieben werden könnte), einige nicht verwendete Speicherfehlertypen zu entfernen und mehr kontextbezogene Informationen zu anderen hinzuzufügen und die Speicherung von Registerbearbeitungsbefehlen für alle Fälle zu ermöglichen (jetzt Die Reihenfolge der eingehenden Befehle sollte weniger wichtig sein, d.h. es gibt keine Race-Condition, um ein CreateRegister Cmd vor einem EditRegister zu haben, das auf main vorhanden ist).

Und @chriso hat die Fehlerbehandlung verbessert in sn_node, einschlieĂźlich der Art von Fehlermeldungen, die an den Client gesendet werden, um es fĂĽr Benutzer einfacher zu machen um zu sehen was los ist.

Nachrichtenserialisierung

Wir haben von @southsides probing gesehen, dass das Netzwerk bei größeren Daten-PUTs unter Stress zu geraten scheint. Seine Tests von 2 GB+ Uploads haben ein Problem dort ans Licht gebracht, das vielleicht ein Teil des Grundes sein könnte… und es könnten einfach zu viele Nachrichten sein.

Das bedeutet nicht, dass wir zu viele versenden (obwohl wir weniger versenden könnten). Aber es sieht so aus, als wäre die Anstrengung, Nachrichten zu formulieren, und die Geschwindigkeit, mit der wir das tun, verdammt zu hoch.

Dies war etwas, das wir seit einiger Zeit in Heaptraces der Speichernutzung des Knotens gesehen haben, aber ein Weg zur Behebung war nicht wirklich klar.

Wir „serialisieren“ jede Nachricht in Bytes, und da wir für jeden Knoten einen anderen „MsgHeader“ erstellen müssen, gab es keinen großen Weg daran vorbei.

Aber was wäre, wenn wir es nicht täten?

Das Stochern von @southside brachte die Frage jedoch wieder in den Vordergrund, und @joshuef, der sich schon seit einiger Zeit über die Menge an Mem ärgert, die durch die Serialisierung verwendet wird, beschloss, sich erneut dagegen zu wehren.

Und dieses Mal kam eine andere Idee auf. Wir haben früher versucht, die Notwendigkeit von Dst (Ziel, Information darüber, wohin die Nachricht gehen soll) zu beseitigen … aber wir können das nicht tun und unsere Anti-Entropie-Ströme am Leben erhalten. Das war also ein Nichtstarter.

Aber nach einigen hackigen Versuchen, die Dst Bytes in einer vorserialisierten Nachricht zu aktualisieren, um diese ganze Arbeit nicht noch einmal machen zu müssen, stellten wir fest, dass wir einen quadratischen Stift in ein rundes Loch zwingen. Die Beschränkung, nur ein „Byte“ einer Nachricht bereitzustellen, machte für uns nämlich keinen Sinn.

SOooOoooo…

Nach einer kleinen Überarbeitung in qp2p, unserem Netzwerk-Wrapper, können wir jetzt drei verschiedene Sätze von Bytes über unsere Verbindungen senden, und davon muss nur einer (unser Dst) tatsächlich geändert werden, wenn wir’ Senden Sie dieselbe Nachricht erneut an verschiedene Knoten!

Das bedeutet statt 7x die Arbeit beim Versenden einer Nachricht an Sektionsälteste 1x - und wir verwenden die Bytes für unseren MsgHeader und Payload wieder! Es muss nur „Dst“ jedes Mal neu codiert werden.

Sauber.

Aber warte … es gibt noch mehr!

Nun, dies ist bereits eine anständige Reduzierung der Rechenkosten für das Senden einer Nachricht. Aber es hat auch einen anderen Anstoß in Bezug auf den Speicher. Zuvor haben wir während der MsgHeader-Serialisierung unseren einen Satz von Bytes gebildet, indem wir die Payload (die eigentliche Nachricht, die wir senden … also ~1MB pro Chunk) kopiert haben, also ist dies etwas Speicherzuweisungsarbeit, und das bedeutet jede Nachricht hatte ihren eigenen eindeutigen Satz von Bytes, die die gleiche Nutzlast repräsentierten. Wenn man also einen Chunk an vier Erwachsene schickt, hat man fünf Kopien dieses Chunks im Gedächtnis. :frowning:

Aber jetzt verwenden wir eine billige Kopie von Bytes (das ist ein Zeigertyp auf die zugrunde liegenden Daten…), sodass keine Duplizierung des Speichers erforderlich ist! Wenn Sie also einen Chunk an vier Erwachsene senden, sollten Sie jetzt nur noch eine Kopie der Daten benötigen :tada:

Endlich

So sieht „main“ aus. Hier sehen wir drei Läufe der 250-Client-Tests (ein PUT mit 5 MB und 250 Clients, die gleichzeitig versuchen, diese Daten zu erhalten), und dann 10 Läufe der vollständigen Standard-Testsuite „sn_client“.

Und das ist auf der ausstehenden PR:

Sie können sehen, dass die Spitzen für diese Tests schneller und mit weniger Gesamtspeicher (~ 900 MB gegenüber 1.800 MB) zu übersteigen scheinen. Und damit misst unser neuer Benchmark den Durchsatz beim Senden einer „WireMsg“ an 1.000 verschiedene „Dsts“.

  • Hauptdurchsatz: 7,5792 MiB/s
  • PR-Durchsatz: 265,25 MiB/s

Was auch ziemlich erfreulich ist.

Der Zweig ist noch nicht zusammengeführt, es müssen noch einige letzte Aufräumarbeiten durchgeführt werden, bevor wir ihn aufnehmen, aber es sieht nach einer vielversprechenden Änderung aus, die Nodes helfen könnte, auf schlankerer Hardware zu laufen (oder @southside hoffentlich mehr auf seine lokalen Testnetze hochladen lässt!? :gekreuzte Finger: )


NĂĽtzliche Links

FĂĽhlen Sie sich frei, unten mit Links zu Ăśbersetzungen dieses Entwicklungsupdates zu antworten, und die Moderatoren werden sie hier hinzufĂĽgen.

Als Open Source-Projekt sind wir immer auf der Suche nach Feedback, Kommentaren und Community-Beiträgen. Seien Sie also nicht schüchtern, machen Sie mit und lassen Sie uns gemeinsam das sichere Netzwerk erstellen!