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
i'm not completely sure where the history is stored, but it is always sent to people joining the room from a browser that hasn't downloaded the history yet. this also happens if the room is empty.
open "about:blank" an anonymous browser tab
open the developer tools network tab and filter by "WS" (WebSockets)
doing the same on other, more fresh rooms doesn't load as much from the server, so i assume this must be the history.
the history is then stored in the browsers IndexDB, so I assume when you come to the page with a populated IndexDB, the server will only give you the diff (which is why the 3.6MB can only be observed from an anonymous tab)
those 3.6MB are a heavily compressed binary format, which gets even larger when converted to JSON. as shown in the post, you can run this in the developer console:
for me, this logs 47937119, which is the number of characters in the (minified) JSON.
1 character is typically 1Byte, so this JSON is around 48MB.
i guess when someone moves the cursor, this data is touched in some way, so it takes a while till the browser can respond again, delaying any callbacks that happen in between (like a strudel clock callback, or anything going on in codemirror).
it would be good if there was a way to prune / delete a session, so the name can remain the same, but the history would vanish. @munshkr do you know where the history is stored? is it handled by @flok-editor/pubsub or by @flok-editor/session ? is there something we can do about it? even needing to manually prune the session would be fine, as this only has to be done once a week or even fewer times (the pastagang session is over 2 months old).
the idea with adding a timestamp feels more like a workaround, because it would probably cause weird bugs in the time of transition + we'd still accumulate a lot of garbage on the server
The text was updated successfully, but these errors were encountered:
longer lived flok sessions steadily accumulate history / memory, which causes the browser to slow down more and more over time.
here's a write up: https://www.pastagang.cc/blog/performance/#long-lived-flok-sessions
i'm not completely sure where the history is stored, but it is always sent to people joining the room from a browser that hasn't downloaded the history yet. this also happens if the room is empty.
doing the same on other, more fresh rooms doesn't load as much from the server, so i assume this must be the history.
the history is then stored in the browsers IndexDB, so I assume when you come to the page with a populated IndexDB, the server will only give you the diff (which is why the 3.6MB can only be observed from an anonymous tab)
those 3.6MB are a heavily compressed binary format, which gets even larger when converted to JSON. as shown in the post, you can run this in the developer console:
for me, this logs 47937119, which is the number of characters in the (minified) JSON.
1 character is typically 1Byte, so this JSON is around 48MB.
i guess when someone moves the cursor, this data is touched in some way, so it takes a while till the browser can respond again, delaying any callbacks that happen in between (like a strudel clock callback, or anything going on in codemirror).
it would be good if there was a way to prune / delete a session, so the name can remain the same, but the history would vanish.
@munshkr do you know where the history is stored? is it handled by @flok-editor/pubsub or by @flok-editor/session ? is there something we can do about it? even needing to manually prune the session would be fine, as this only has to be done once a week or even fewer times (the pastagang session is over 2 months old).
the idea with adding a timestamp feels more like a workaround, because it would probably cause weird bugs in the time of transition + we'd still accumulate a lot of garbage on the server
The text was updated successfully, but these errors were encountered: