Multiple tab customizable benchmark

[rhashimoto]

I created a demo page to try to measure write transaction performance across multiple browser tabs, each with their own database connection. It looks like it might be useful for more than that, e.g. I used it for these measurements for a single connection. It's only under the breaking-changes branch right now, but there's a live version available here. Note that this demo uses dynamic import in an ES6 module Worker, which is not supported in Firefox stable yet; it does work in Firefox nightly.

If you open the page using the default link above, it will use the IDBBatchAtomicVFS. You can append a query parameter, vfs=some-vfs-label to use a different VFS. Here's what is supported now:

• ?vfs=IDBBatchAtomicVFS - Uses IDBBatchAtomicVFS, which is the default.
• ?vfs=IDBMinimalVFS - Uses IDBMinimalVFS.
• ?vfs=IDBBatchAtomicVFS-relaxed - IDBBatchAtomic with relaxed durability.
• ?vfs=IDBMinimalVFS-relaxed - IDBMinimalVFS with relaxed durability.
• ?vfs=OriginPrivateFileSystemVFS - OriginPrivateFileSystemVFS does not work on multiple tabs with some non-default journal modes.
• ?vfs=AccessHandlePoolVFS - AccessHandlePoolVFS only works with a single tab. See this idea to allow multiple tabs to share a connection.

On an opened page, you can open additional browser tabs by clicking the "Open new tab" button. The number of tabs shown above the button will change as new tabs using the same VFS are opened or closed.

Once however many browser tabs you want are open (1 is fine), click the "Start test" button on one of the tabs. Each tab will then execute as many queries as it can before a fixed deadline, 10 seconds by default, and then will query and display the results. Here's a sample screenshot:

Here I had opened three tabs and the test was for the default 10 seconds. The tabs completed 186, 186, and 185 transactions, respectively, which in aggregate was 55.7 transactions per second. In addition to the transaction rate, note also that the transactions are perfectly balanced, which shows that the VFS synchronization (with Web Locks) is fair and no tab is starved of access.

That's already pretty interesting, but if you want you can customize the measurements by opening the "Advanced configuration" area. There you can set the test duration and four SQL queries:

• Per run initialization - This query is only run on the tab where you start the test. It is intended to be used to set up and reset the database. The default query creates two tables: a key-value table that holds a counter, and a logging table that will contain a row for each transaction.
• Per tab initialization - This query is run once by each tab. It is intended to be used to set up database connection state. You might use it to create temporary tables or set PRAGMAs. The default query does nothing.
• Per job - This query is repeatedly submitted by each tab until time expires. You might use it to create a transaction that simulates the complexity and size of your application transactions. The default query uses a transaction within which it increments a counter and inserts a log entry.
• Results - This query provides results on each tab. Any statement output will be appended to the page. The default query removes any log entries with a timestamp past the deadline, then counts and sums the entries by each tab.

Custom queries can use a few variable placeholders (see their use in the default queries):

• :tabId - will be replaced with the tab id, which is a randomly generated string
• :deadline - will be replaced with the end time of the test, denoted in milliseconds since the UNIX epoch
• :seconds - the duration of the test