Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intelligenteres Syncen: mehr im RAM halten #7

Open
the-infinity opened this issue Feb 27, 2020 · 0 comments
Open

Intelligenteres Syncen: mehr im RAM halten #7

the-infinity opened this issue Feb 27, 2020 · 0 comments

Comments

@the-infinity
Copy link
Contributor

Bislang basiert der Daemon massiv auf MongoDB Upserts. Das ist zwar jeweils immer nur ein Request / Objekt, aber bedingt durch die vielen Objekt-Verknüpfungen sind das trotzdem extrem viele Requests, so dass bei einem Full Update extrem viele Requests auf die MongoDB gemacht werden. Es wäre vermutlich intelligenter, pro Stadt einfach einen Zusammenhang ID -> modified aller Objekte in den RAM zu laden und dann gegen den RAM zu checken, ob sich etwas verändert hat. Das würde insbesondere bei den verlinkten Objekten eine deutliche Beschleunigung ergeben.

Konkret: aktuell mache ich zich schreibende Requests im Beispiel von Organization: https://oparl.org/spezifikation/online-ansicht/#entity-organization , u.a. für jede Membership (was nur eine ID ist, die dann da abgespeichert wird), ebenso wie für Location. Hätte man ID + modified im RAM, so könnte man die Existenz von Membership und das Änderungsdatum von Location schlicht testen und nur dann abspeichern, wenn es überhaupt ein neues Objekt ist / eine Änderung gab.

Pro Kommune sind die ID -> modified Zuordnungen auch begrenzt: wenn man annimmt, dass eine URL bis zu 128 Zeichen lang ist, dann macht das 128 Byte * 500.000 Dokumente (was weit über der größten Kummune aktuell ist) = 64 MB RAM-Verbrauch. Mit gespeicherten Datetimes in einem riesigen Dict sind das in einem Realtest 227 MB VSZ und 156 MB RSS, was bei maximal 8 auf einem 8-Kern-System gleichzeitigen Prozessen eine Maximalauslastung von unter 2 GB ausmacht. Wenn dadurch wirklich nennenswert Datenbanklast eingespart werden kann, ist dies für einen Server mit 32 oder sogar 64 GB RAM ein Klacks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant