Ausgangswerte für Speicherung und Synchronisierung
Führen Sie vom Repository-Stamm aus einen synthetischen Benchmark mit temporären Testdaten aus:
cargo run -p memories-core --example storage_benchmark --release --locked -- 10,100,1000
Jeder Fall erstellt zwei temporäre Geräte, koppelt sie, schreibt die angeforderte Anzahl gewöhnlicher Datensätze mit jeweils 960 Byte, führt eine Suche durch, exportiert einen vollständigen Tresor und öffnet die verschlüsselte Datenbank erneut. Temporäre Verzeichnisse werden beim Beenden entfernt. Die Ausgabe erfolgt als JSONL; es werden weder ein echter Tresor noch ein Cloud-Konto verwendet. Die Standardfälle umfassen 100 und 1000 Anlagen.
Lokale Beobachtungen unter Windows x86_64 / Rust 1.98.1 MSVC am 2026-09-17:
| Anlagen | Speichern p50 / p95 (ms) | Suche (ms) | Entsperren (ms) | Datenbank-Bytes | Bytes der vollständigen Synchronisierungsantwort | Kumulativ geschriebene Bytes des serialisierten Zustands |
|---|---|---|---|---|---|---|
| 10 | 5.96 / 7.20 | 10.29 | 146.45 | 147456 | 57255 | 297346 |
| 100 | 8.56 / 13.06 | 42.39 | 206.50 | 1126400 | 509912 | 21224694 |
| 1000 | 56.75 / 108.40 | 252.95 | 825.76 | 9175040 | 4162849 | 2038518604 |
Der Pfad zum Anhängen von Audit-Einträgen leitete zuvor denselben öffentlichen Geräteschlüssel einmal für jeden vorhandenen Audit-Eintrag ab. Die einmalige Berechnung je Anhängevorgang erhält die signierte Kette und beseitigt zugleich wiederholte kryptografische Arbeit. Vor dieser Änderung benötigten dieselben Suchen über 100/1000 Datensätze 552.71/2476.66 ms. Dies sind einzelne lokale Durchläufe, keine statistisch kontrollierten Messungen oder plattformübergreifenden Zusicherungen; gleichzeitig liefen weitere Validierungs- und Build-Arbeiten auf dem Host.
serialized_state_bytes_written summiert die Länge der verschlüsselten Zustandszeile nach jedem
Einfügen einer Anlage. Nicht enthalten sind Checkpoints, Journale, zusätzliche Schreiblast des Dateisystems und
spätere Schreibvorgänge durch Suche/Export; dies ist kein Zähler physischer Schreibvorgänge auf dem Datenträger. Die Exportgröße
enthält die JSON-Antwort. Die Suche liefert höchstens 100 Ergebnisse. Spitzenverbrauch des Arbeitsspeichers,
große binäre Anlagen, Verteilung auf mehrere Geräte und mobile Latenz müssen noch profiliert werden.
Abgeschlossene Cloud-Uploads/-Downloads geben jetzt ihre Chiffretext-Puffer frei und behalten kleine Wiederholungsbelege und Veröffentlichungsmarkierungen. Die Warteschlangenkapazität gilt für ausstehende Arbeit. Der entfernte Verlauf und kompakte lokale Hash-Belege bleiben erhalten; aus einem erfolgreichen Upload wird weder eine Löschung in der Cloud noch eine Bestätigung durch ein Offline-Gerät abgeleitet.
Das kumulative Schreibvolumen bestätigt, dass die Persistierung des gesamten Zustands weiterhin für kleine Bibliotheken ausgelegt ist. Verschlüsselte Zeilen je Revision und inkrementeller Transport sind eine separate Format-/Migrationsänderung, für die Sicherungs- und Rollback-Validierung erforderlich sind, bevor das vorhandene transaktionale Format ersetzt wird. Legen Sie anhand dieser reproduzierbaren Messungen zuerst eine unterstützte Größe und ein Latenzbudget für die Veröffentlichung fest.