Integrating continuous benchmarking from js-logger

[CMCDragonkai]

Description

This brings in some synchronisation with js-logger and continuous benchmarking

Issues Fixed

• Related https://github.com/MatrixAI/Orchestrator/issues/25

Tasks

• 1. Updated continuous benchmarking framework
• 2. Updated testing dependencies
• 3. Updated .gitlab-ci.yaml to run benchmarks
• 4. Changed to using nix-shell --arg ci true --run $'' to ensure strict error checking AND also allow C-style string escaping
• 5. Upgraded ts-node to using swc

Final checklist

• Domain specific tests
• Full tests
• Updated inline-comment documentation
• Lint fixed
• Squash and rebased
• Sanity check the final build

[ghost]

👇 Click on the image for a new way to code review

• Make big changes easier — review code in small groups of related files

• Know where to start — see the whole change at a glance

• Take a code tour — explore the change with an interactive tour

• Make comments and review — all fully sync’ed with github

  Try it now!

Legend

[CMCDragonkai]

Here are the differences from the previous benchmark. This is run with fixed-cpu-run npm run bench. The top array line is before. The new metrics report is afterwards.

[43375, 24504, 27503, 13785],

db_1KiB_ops{name="get 1 KiB of data"} 48563
db_1KiB_ops{name="put 1 KiB of data"} 39043
db_1KiB_ops{name="put zero data"} 40984
db_1KiB_ops{name="put zero data then del"} 21108

[570, 543, 29963, 13694],

db_1MiB_ops{name="get 1 MiB of data"} 821
db_1MiB_ops{name="put 1 MiB of data"} 638
db_1MiB_ops{name="put zero data"} 41831
db_1MiB_ops{name="put zero data then del"} 20022

The main thing to see here is that puts have become much faster 1.59x faster, while gets are getting back similar to leveldb speeds. Prior leveldb was even using the boosted CPU.

I suspect the biggest speed at this point will be due to usage of native transactions inside rocksdb, however I have not started measuring transactions yet.

Also note that these are unencrypted performance. Encryption is not involved here because it will seriously affect the speed until we move to using native crypto. Further benchmarking can be done with DB plus crypto subsequently.

[CMCDragonkai]

@tegefaulkes see benchmark data above.

[CMCDragonkai]

Error indicates that js-logger needs to be updated on js-workers first. Otherwise the strict type checking is failing. @emmacasolin

[emmacasolin]

Error indicates that js-logger needs to be updated on js-workers first. Otherwise the strict type checking is failing. @emmacasolin

Just updated js-workers since js-polykey needs efs to be updated and efs needs js-workers, but it's not letting me push up the version tag for v1.3.4 of js-workers

remote: error: GH006: Protected tag update failed for refs/tags/v1.3.4.
remote: error: You're not authorized to create a tag
To github.com:MatrixAI/js-workers.git
 ! [remote rejected] v1.3.4 -> v1.3.4 (protected tag hook declined)
error: failed to push some refs to 'github.com:MatrixAI/js-workers.git'

As a side-note efs also needs js-db to be updated so I won't be able to proceed until js-logger gets updated here.

[CMCDragonkai]

Permissions updated, you should be able to push protected tags to js-logger now.

[CMCDragonkai]

1.3.5 of js-workers is being staged.

[CMCDragonkai]

Going to merge now, and do the rest in staging.