You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: