Dirty table reads to check #5325
Comments
juliushaertl
added
bug
|
@juliushaertl should we close this for now, given that we did quite a bit of refactoring of create/sync/push? Or would you like to keep it open? |
|
Let's keep it open, still worth to check again after all the changing bits are merged |
|
@hweihwang I think this could be a good starter to dive a bit into the sync backend endpoint of the text app in preparation for future work. The main goal is to avoid read after write on the same rows. We did some rework of the backend since the issue was filed, so it would be good to generate some logs to check again on opening, editing a text document, saving and closing it. The logging that was added in nextcloud/server#42345 to the server can help there but is probably only a first hint. It would still be needed to check the affected queries in detail to see if the rows read are actually problematic, as the log does only track dirty writes depending on the table, not the actual rows writen or read. |
|
|
On /save endpoint: In SessionMiddleware and beforeController hook:
|
|
Here are some of my initial thoughts about potential optimizations to decrease database workloads and improve performance:
|
Could you file separate issues about those, so we can discuss this with Max? I'd also agree with that the debounce on writing could certainly be decreased a bit. Though we want to not lower it too much to still have a almost instant sync.
Regarding what system we can use we are somewhat limited to what we integrate with Nextcloud server already as having another component as an additional dependency is out of scope (like a document store). As mentioned in the call, I have some mixed feelings about this. On the one hand this could certainly help to reduce the db load, however the queries itself are rather fast and we'd need to think carefully how we could store the often updating data within available redis structures. We would also always need the database as a fallback for small systems that run without it. Maybe we can also file a separate issue about that to collect what we could potentially store in cache (in addition to the db) for faster reads. (Apart from the synced steps I could also imagine storing the saved ydoc itself which could speed up file openings then and avoid a file read from disk). |
Right, this sounds like whenever a controller has two checks as PHP attributes we would run into this. Maybe we just store the requested document in the middleware and reuse it then to not query twice. We may also just check if the controller already has a document set and use that instead of querying the db again. |
Create
Push
Sync
Save
Close
The text was updated successfully, but these errors were encountered: