Dies ist eine Übersetzung des Original-Artikel geschrieben von @blocktrades zur Arbeit an der Hive Software: https://peakd.com/hive-139531/@blocktrades/13th-update-of-2021-on-blocktrades-work-on-hive-software (Veröffentlicht: Dienstag 25 Mai 2021)
Nachfolgend eine Auflistung einiger Hive-bezogener Programmieraufgaben, an denen das BlockTrades-Team in den letzten Wochen gearbeitet hat:
Hived Work (Blockchain Node Software)
Wir testen weiter und nehmen Korrekturen vor, um einen zweiten Release Candidate für hived zu erstellen.
Wir haben eine neue Python-basierte Bibliothek mit dem Namen "testtools" erstellt, um Testszenarien für hived und die CLI-Wallet von hived zu erstellen. Wir ersetzen damit die beempy-Bibliothek, die bisher für diesen Zweck verwendet wurde, um die Ausführungsgeschwindigkeit der Tests zu beschleunigen.
Im Moment ist der Hauptzweck dieser Python-Bibliothek das Testen von hived, aber sie könnte allgemeiner als Bibliothek für die Kommunikation mit hived anwendbar sein, in diesem Fall werden wir sie später in etwas Passenderes umbenennen:
https://gitlab.syncad.com/hive/hive/-/merge_requests/242
Wir haben einige auf Unit-Tests basierende Stresstests für die neue Funktionalität der wiederkehrenden Übertragungen erstellt und fanden zunächst einige überraschende Ergebnisse in Bezug auf die Speichernutzung, aber letztendlich wurde dies auf eine Fehlkonfiguration der Hived-Instanz zurückgeführt (sie war mit dem veralteten chainbase account history-Plugin konfiguriert, das dafür bekannt ist, zu viel Speicher zu verbrauchen). Nachdem dieses Plugin durch das Plugin rocksdb-account-history ersetzt wurde, waren der Speicherverbrauch und die allgemeine Leistung in Ordnung.
Wir haben auch einige kleinere Probleme mit dem wiederkehrenden Transfervorgang behoben:
https://gitlab.syncad.com/hive/hive/-/merge_requests/246
Wir haben ein paar neue Netzwerk-API-Aufrufe zu hived hinzugefügt, um die Anzahl der Peers zu ermitteln, verbundene Peers zu ermitteln, Peers hinzuzufügen und erlaubte Peers zu setzen. Diese Funktionen wurden in erster Linie hinzugefügt, um Testszenarien zu erleichtern (z. B. das Testen der Forking-Logik), sie können aber auch für Nodebetreiber nützlich sein:
https://gitlab.syncad.com/hive/hive/-/merge_requests/244
Wir haben Unterstützung für die Erstellung mit boost 1.70 hinzugefügt (getestet auf Ubuntu 18 und 20).
Wir haben auch die fc-Bibliothek geändert, um eine vereinfachte Protokollierungssyntax zu ermöglichen. Zum Beispiel, anstatt von:
ilog(“my variable=${my_variable}”,(“my_variable”,my_variable));
kannst du einfach:
ilog(“my variable=${my_variable}”,(my_variable));
verwenden.
Hinweis: Die ältere Syntax ist weiterhin erforderlich, wenn Du eine Funktion für die Variable aufrufen musst, um den zu protokollierenden Wert zu erhalten. Die beiden Syntaxen können in einer einzigen Log-Anweisung gemischt werden.
Bei unseren Tests zur Behebung des langjährigen Fehlers "doppelte Operationen in der Kontohistorie" haben wir festgestellt, dass dieses Problem auch auftreten kann, wenn der Wert des letzten irreversiblen Blocks als Teil des Herunterfahrens von hived "rückgängig" gemacht wird (d. h. wenn ein Nodeoperator Strg-C drückt, um die Node herunterzufahren). Bei einem nachfolgenden Start, bei dem der letzte irreversible Block auf einen früheren Block gesetzt wurde, würde der Code die Operationen aus den bereits bearbeiteten Blöcken wieder einfügen. Um dieses Problem zu beheben, stellen wir sicher, dass die Nummer des irreversiblen Blocks nicht mehr durch die Operation zum Rückgängigmachen des Datenbankzustands rückgängig gemacht werden kann.
Sobald das obige Problem behoben ist und im Replay-Modus in Verbindung mit einer vollständigen Synchronisation von hivemind getestet wurde, werden wir einen zweiten Release Candidate für das Testnet bereitstellen (wahrscheinlich Donnerstag oder Freitag). Sofern keine unerwarteten Probleme während der Testnet-Tests auftreten, gehe ich davon aus, dass dies unser letzter Release Candidate vor der offiziellen Veröffentlichung sein wird, basierend auf den bisherigen Testergebnissen.
Hivemind (Anwendungen im 2. Layer + Middleware für soziale Medien)
In der letzten Woche haben wir letzte Korrekturen vorgenommen und Leistungstests durchgeführt, um eine neue Version von hivemind für API-Nodebetreiber im Laufe dieser Woche vorzubereiten.
Wechsel zurück zur Verwendung von pip für die Installation von hivemind
Wir haben kürzlich festgestellt, dass unsere aktuelle Installationsmethodik für hivemind zu unerwarteten Problemen bei der Paketversionierung führen kann. Daher wechseln wir wieder zur Verwendung von pip (python package installer) und pinnen die Versionen der Pakete an, die hivemind verwendet.
Leistungsprüfung und -optimierung für hivemind
Beim Testen des Entwicklungszweigs von hivemind auf unserer Produktions-API-Node (https://api.hive.blog) bemerkten wir eine Verlangsamung der Leistung der Abfrage bridge_get_ranked_post_by_created_for_tag (ging von durchschnittlich 64ms auf fast 2s Durchschnittszeit).
Dieses Problem wurde letztlich darauf zurückgeführt, dass nicht genügend Statistiken für die Spalte tags_ids in der Tabelle hive_posts gesammelt wurden. Die gesammelten Statistiken reichten nicht aus, um die Wahrscheinlichkeitsverteilung der von Beiträgen verwendeten Tags zu modellieren, was dazu führte, dass der Abfrageplaner einen leistungsschwachen Abfrageplan auswählte.
Interessant ist hier, dass es sich um ein latentes Leistungsproblem handelte, das potenziell auf jedem beliebigen API-Knoten hätte auftreten können, wenn er einen unglücklichen Statistiksatz gesammelt hätte (das Problem war nicht wirklich ein Master- vs. Entwicklungszweig-Problem). Wir haben das Problem behoben, indem wir die für diese Spalte gesammelten Statistiken von 100 auf 1000 erhöht haben: https://gitlab.syncad.com/hive/hivemind/-/merge_requests/503
Hivemind-Speicherverbrauch
Wir erforschen immer noch mögliche Wege, um den Speicherverbrauch durch den Hivemind-Synchronisationsprozess im Laufe der Zeit zu verringern. Wir haben den Speicherverbrauch etwas reduziert, aber mehr scheint möglich.
Postgres 13 vs Postgres 10 für hivemind
Während unserer Suche nach einer möglichen Lösung für das obige Problem (bevor wir erkannten, dass das Erhöhen der Statistiken die beste Lösung war), haben wir auch versucht, unsere SQL-Datenbank von Postgres 10 mit Postgres 13 zu aktualisieren, um zu sehen, ob es einen besseren Abfrageplan auswählen würde.
Das Datenbank-Upgrade hatte keinen Einfluss auf das obige Problem, aber wir fanden eine weitere Verlangsamung während der Hive-Synchronisation (der Indexer, der Daten aus der Blockchain zur Datenbank hinzufügt), die mit Postgres 13 verbunden ist. Dieses Problem tritt auf, weil der postgres13-Planer die Kosten für die Aktualisierung der rshare-Summen während der "Live-Synchronisation" falsch einschätzt und beschließt, eine Just-in-Time-Optimierung (jit) durchzuführen, die die Abfragezeit um 100 ms verlängert (update_posts_rshares liegt normalerweise bei durchschnittlich 3 ms).
Wir bestätigten, dass dies das Problem war, indem wir den Schwellenwert für die Kosten erhöhten, die erforderlich waren, bevor der Planer die Jit-Optimierung anwenden durfte (und damit die Jit-Verwendung in der Abfrage deaktivierten). In diesem Szenario war die Leistung für Postgres 13 nur geringfügig besser als für 10. Sobald wir auf 13 umsteigen, müssen wir eine langfristige Lösung für dieses Problem auswählen (entweder die Kostenschätzung verbessern oder einfach Jit für diese Abfrage deaktivieren), aber das ist ein Thema für einen späteren Tag.
Funktionstests und Korrekturen für hivemind
Während der Arbeit an den Korrekturen der Community-bezogenen API-Aufrufe haben wir auch die Mock-Testing-Funktionen verbessert, um die Änderungen zu verifizieren (Mock-Testing ermöglicht es uns, "gefälschte" Daten zu Testzwecken in einen bestehenden Hivemind-Datensatz zu generieren).
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/496
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/499
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/501
Modular hivemind (Framework für HIVE Anwendungen)
Wir bauen derzeit eine Beispielanwendung mit dem Prototyp für unser modulares hivemind-Framework, das die Kontoverlaufs-API unterstützen wird. Wir hoffen, dass wir irgendwann nächste Woche einen vollständigen Test dieser Beispielanwendung durchführen können.
Condenser Wallet
Wir haben einige Condenser Wallet-Tests durchgeführt und Fehler behoben. Wir haben einen Fehler in der neuen Funktion von @quochuy behoben, die eine CSV-Datei mit der Transaktionshistorie eines Benutzers erzeugt. Der Fix wurde auf https://wallet.hive.blog eingespielt.
https://gitlab.syncad.com/hive/wallet/-/merge_requests/106
Testnet
Wir haben ein paar mutige Personen, die einige Tests mit dem Testnet durchgeführt haben, aber ich würde gerne viel mehr sehen, insbesondere von Benutzern, die Hive-API-Bibliotheken und Hive-basierte Anwendungen unterstützen.
Aber jeder ist willkommen, im Testnet herumzuspielen und zu versuchen, Dinge kaputt zu machen. Als normaler Hive-Benutzer kannst du dich mit deinen normalen Anmeldedaten anmelden über:
https://testblog.openhive.network (hive.blog-ähnliche Testseite)
oder
https://testnet.peakd.com/ (peakd-ähnliche Testseite)
Du kannst das Testnet auch mit diesem Block-Explorer durchsuchen: https://test.ausbit.dev/
In Zukunft sollte das Testnet das bevorzugte Mittel für erste Tests von Hive-Anwendungen sein. Und das Testen neuer Funktionen jetzt, vor dem Hardfork, hilft uns, Bereiche zu identifizieren, in denen wir eventuell Änderungen an API-Antworten usw. vornehmen wollen, bevor es eine "offizielle" API-Antwort gibt, die dann später geändert werden muss.
Geplantes Datum für den Hardfork 25
Ich gehe immer noch davon aus, dass der Hardfork in der letzten Juniwoche stattfinden wird.