Currently this repository hosts two kinds of benchmarks:
- The older "milli benchmarks", that use criterion and live in the "benchmarks" directory.
- The newer "bench" that are workload-based and so split between the
workloads
directory and thextask::bench
module.
This document describes the newer "bench" benchmarks. For more details on the "milli benchmarks", see benchmarks/README.md.
The newer "bench" benchmarks are integration benchmarks, in the sense that they spawn an actual Meilisearch server and measure its performance end-to-end, including HTTP request overhead.
Since this is prone to fluctuating, the benchmarks regain a bit of precision by measuring the runtime of the individual spans using the logging machinery of Meilisearch.
A span roughly translates to a function call. The benchmark runner collects all the spans by name using the logs route and sums their runtime. The processed results are then sent to the benchmark dashboard, which is in charge of storing and presenting the data.
Benchmarks can run locally or in CI.
The benchmarks dashboard lives in its own repository. We provide binaries for Ubuntu/Debian, but you can build from source for other platforms (MacOS should work as it was developed under that platform).
Run the benchboard
binary to create a fresh database of results. By default it will serve the results and the API to gather results on http://localhost:9001
.
From the Meilisearch repository, you can then run benchmarks with:
cargo xtask bench -- workloads/my_workload_1.json ..
This command will build and run Meilisearch locally on port 7700, so make sure that this port is available. To run benchmarks on a different commit, just use the usual git command to get back to the desired commit.
To work with the raw results, you can also skip using a local benchmark dashboard.
Run:
cargo xtask bench --no-dashboard -- workloads/my_workload_1.json workloads/my_workload_2.json ..
For processing the results, look at Looking at benchmark results/Without dashboard.
Sometimes you want to visualize the metrics of a worlkoad that comes from a custom report. It is not quite easy to trick the benchboard in thinking that your report is legitimate but here are the commands you can run to upload your firefox report on a running benchboard.
# Name this hostname whatever you want
echo '{ "hostname": "the-best-place" }' | xh PUT 'http://127.0.0.1:9001/api/v1/machine'
# You'll receive an UUID from this command that we will call $invocation_uuid
echo '{ "commit": { "sha1": "1234567", "commit_date": "2024-09-05 12:00:12.0 +00:00:00", "message": "A cool message" }, "machine_hostname": "the-best-place", "max_workloads": 1 }' | xh PUT 'http://127.0.0.1:9001/api/v1/invocation'
# Just use UUID from the previous command
# and you'll receive another UUID that we will call $workload_uuid
echo '{ "invocation_uuid": "$invocation_uuid", "name": "toto", "max_runs": 1 }' | xh PUT 'http://127.0.0.1:9001/api/v1/workload'
# And now use your $workload_uuid and the content of your firefox report
# but don't forget to convert your firefox report from JSONLines into an object
echo '{ "workload_uuid": "$workload_uuid", "data": $REPORT_JSON_DATA }' | xh PUT 'http://127.0.0.1:9001/api/v1/run'
We have dedicated runners to run workloads on CI. Currently, there are three ways of running the CI:
- Automatically, on every push to
main
. - Manually, by clicking the
Run workflow
button and specifying the target reference (tag, commit or branch) as well as one or multiple workloads to run. The workloads must exist in the Meilisearch repository (conventionally, in theworkloads
directory) on the target reference. Globbing (e.g.,workloads/*.json
) works. - Manually on a PR, by posting a comment containing a
/bench
command, followed by one or multiple workloads to run. Globbing works. The workloads must exist in the Meilisearch repository in the branch of the PR.
/bench workloads/movies*.json /hackernews_1M.json
Results are available on the global dashboard used by CI at https://bench.meilisearch.dev or on your local dashboard.
The dashboard homepage presents three sections:
- The latest invocations (a call to
cargo xtask bench
, either local or by CI) with their reason (generally set to some helpful link in CI) and their status. - The latest workloads ran on
main
. - The latest workloads ran on other references.
By default, the workload shows the total runtime delta with the latest applicable commit on main
. The latest applicable commit is the latest commit for workload invocations that do not originate on main
, and the latest previous commit for workload invocations that originate on main
.
You can explicitly request a detailed comparison by span with the main
branch, the branch or origin, or any previous commit, by clicking the links at the bottom of the workload invocation.
In the detailed comparison view, the spans are sorted by improvements, regressions, stable (no statistically significant change) and unstable (the span runtime is comparable to its standard deviation).
You can click on the name of any span to get a box plot comparing the target commit with multiple commits of the selected branch.
After the workloads are done running, the reports will live in the Meilisearch repository, in the bench/reports
directory (by default).
You can then convert these reports into other formats.
- To Firefox profiler format. Run:
You can then upload the resulting
cd bench/reports cargo run --release --bin trace-to-firefox -- my_workload_1-0-trace.json
firefox-my_workload_1-0-trace.json
file to the online profiler.
Benchmark workloads conventionally live in the workloads
directory of the Meilisearch repository.
They are JSON files with the following structure (comments are not actually supported, to make your own, remove them or copy some existing workload file):
Assets reside in our DigitalOcean S3 space. Assuming you have team access to the DigitalOcean S3 space:
- go to https://cloud.digitalocean.com/spaces/milli-benchmarks?i=d1c552&path=bench%2Fdatasets%2F
- upload your dataset:
- if your dataset is a single file, upload that single file using the "upload" button,
- otherwise, create a folder using the "create folder" button, then inside that folder upload your individual files.
The URL of the server is in our password manager (look for "benchboard").
- Make the needed modifications on the benchboard repository and merge them to main.
- Publish a new release to produce the Ubuntu/Debian binary.
- Download the binary locally, send it to the server:
scp -6 ~/Downloads/benchboard root@\[<ipv6-address>\]:/bench/new-benchboard
Note that the ipv6 must be between escaped square brackets for SCP. 4. SSH to the server:
ssh root@<ipv6-address>
Note the ipv6 must NOT be between escaped square brackets for SSH 🥲 5. On the server, set the correct permissions for the new binary:
chown bench:bench /bench/new-benchboard
chmod 700 /bench/new-benchboard
- On the server, move the new binary to the location of the running binary (if unsure, start by making a backup of the running binary):
mv /bench/{new-,}benchboard
- Restart the benchboard service.
systemctl restart benchboard
- Check that the service runs correctly.
systemctl status benchboard
- Check the availability of the service by going to https://bench.meilisearch.dev on your browser.