Performance on NSF filesystems.

[ellisonbg]

Description

As I mentioned in #49, we are testing this on NFS filesystems and finding performance problems. On these file systems, we see that with a small number of editors of a document (around 5) once users stop typing, they continue to see changes from other users from around 30 seconds. We have traced this back to the performance of sqlite on NFS. We have validated that moving the sqlite db to a different (and faster) filesystem resolves the issues, but this is not always possible.

Reproduce

1. Setup and use RTC on an NFS filesystem.
2. Have >=5 users type for a few minutes.
3. Have everyone stop typing.
4. Everyone will see changes continue to show up for at least 30 seconds.

Expected behavior

NFS is a very important file system for Jupyter and is often the default in a JupyterHub deployment. We should think more about how we can address the performance issues of sqlite in this case, and possibly find a better alternative.

[davidbrochart]

As I mentioned in this comment, you can also use another backend for storing Y updates, for instance a file or a temporary file, to check that the issue is really related to SQLite.
To test "slow" filesystems like NFS, we could also create a test backend that would emulate long access times, what do you think?