Can I limit intensity of fsync's of webappstore(localstorage) sqlite db?

Question

Modern browsers have local storage, which is stored in webappstore.sqlite (for firefox) and localstorage.sqlite (for chrome).

There is a third-party script, (online messenger), which uses local storage and changes some value every second (chrome) or even more often (firefox, 2-3 time per second).

Local storage key which is changed so often:

_STRG_fm_current

script is webagent-04052011092843.js

I think, that sqlite engine in broswer do a fsync every time (or every second) when the values in local storage is changed. Using Filemon, I also detected work with .sqlite-journal files, but they are deleted when I try to find them in the folder with localstorage.

Is it possible to limit how often will sqlite do fsyncs of localstorage db's in firefox and chrome?

Answer 1

If you have a web app that is using local storage so heavily that it causes performance issues, I would contact the web app author and let them know, so perhaps they can fix it.

However, SQLite does have a mode since version 3.7.0 called write-ahead logging which uses fewer fsync operations. Since newer versions of Chrome and Firefox both use at least version 3.7.0 of SQLite, you may be able to set WAL mode on your local storage database, and it ought to persist when Chrome and Firefox start using it.

You will need the sqlite3 executable. Close Chrome first, then run the following commands:

sqlite3 path/to/localstorage.sqlite

sqlite> PRAGMA journal_mode=WAL;
sqlite> .quit

(When you run the PRAGMA command, you should get back the result "wal".)

The same commands would be used to set WAL mode for the Firefox database, substituting webappstore.sqlite for localstorage.sqlite.

To undo this setting, run the same commands, except use PRAGMA journal_mode=DELETE;.

Please note that I have not tried this myself; my guess is that it will work fine, but I urge you to backup the database file before trying it.

---

As an aside, the *.sqlite-journal files you are seeing in Filemon are part of how SQLite performs an atomic commit. By default, the journal file exists only for a very short time. When committing a change to a SQLite database, the following actions happen:

1. The current data is written to the journal file.
2. The new data is written to the database file.
3. The journal file is deleted.

If the computer crashes in the middle of writing the database file, the journal file is used to recover the database back to before the change ever started.