|
| 1 | +# A benchmark suite for relational database connection crates in rust |
| 2 | + |
| 3 | +This directory contains a basic benchmark suite that allows to compare different crates that can be used to connect to relational database systems. Those benchmarks are created with the following goals: |
| 4 | + |
| 5 | +a) To track diesels performance and find potential regressions |
| 6 | +b) To evaluate potential alternatives for the currently used C-dependencies |
| 7 | +c) To compare diesel with the competing crates |
| 8 | + |
| 9 | +It currently supports the following database systems: |
| 10 | + |
| 11 | +* PostgreSQL |
| 12 | +* MySQL/MariaDB |
| 13 | +* SQLite |
| 14 | + |
| 15 | +and the following crates: |
| 16 | + |
| 17 | +* Diesel |
| 18 | +* [SQLx](https://github.com/launchbadge/sqlx) |
| 19 | +* [Rustorm](https://github.com/ivanceras/rustorm) |
| 20 | +* [Quaint](https://github.com/prisma/quaint) |
| 21 | +* [Postgres](https://github.com/sfackler/rust-postgres) |
| 22 | +* [Rusqlite](https://github.com/rusqlite/rusqlite) |
| 23 | +* [Mysql](https://github.com/blackbeam/rust-mysql-simple) |
| 24 | + |
| 25 | +By default only diesels own benchmarks are executed. To run the benchmark do the following: |
| 26 | + |
| 27 | +```sh |
| 28 | +$ DATABASE_URL=your://database/url diesel migration run --migration-dir ../migrations/$backend |
| 29 | +$ DATABASE_URL=your://database/url cargo bench --features "$backend" |
| 30 | +``` |
| 31 | + |
| 32 | +To enable other crates add the following features: |
| 33 | + |
| 34 | +* `SQLx: ` `sqlx sqlx/$backend async-std` |
| 35 | +* `Rustorm`: `rustorm rustorm/with-$backend rustorm_dao` |
| 36 | +* `Quaint`: `quaint quaint/$backend tokio quaint/serde-support serde` |
| 37 | +* `Postgres`: `rust-postgres` |
| 38 | +* `Rusqlite`: `rusqlite` |
| 39 | +* `Mysql`: `rust-mysql` |
| 40 | + |
| 41 | +## Benchmarks |
| 42 | + |
| 43 | +### Common data structures |
| 44 | + |
| 45 | +#### Table definitions |
| 46 | + |
| 47 | +The following schema definition was used. (For Mysql/Sqlite postgres specific types where replaced by their equivalent type). |
| 48 | +```sql |
| 49 | +CREATE TABLE users ( |
| 50 | + id SERIAL PRIMARY KEY, |
| 51 | + name VARCHAR NOT NULL, |
| 52 | + hair_color VARCHAR |
| 53 | +); |
| 54 | + |
| 55 | +CREATE TABLE posts ( |
| 56 | + id SERIAL PRIMARY KEY, |
| 57 | + user_id INTEGER NOT NULL, |
| 58 | + title VARCHAR NOT NULL, |
| 59 | + body TEXT |
| 60 | +); |
| 61 | + |
| 62 | +CREATE TABLE comments ( |
| 63 | + id SERIAL PRIMARY KEY, |
| 64 | + post_id INTEGER NOT NULL, |
| 65 | + text TEXT NOT NULL |
| 66 | +); |
| 67 | + |
| 68 | +``` |
| 69 | + |
| 70 | + |
| 71 | + |
| 72 | + |
| 73 | +#### Struct definitions |
| 74 | + |
| 75 | +```rust |
| 76 | +pub struct User { |
| 77 | + pub id: i32, |
| 78 | + pub name: String, |
| 79 | + pub hair_color: Option<String>, |
| 80 | +} |
| 81 | + |
| 82 | +pub struct Post { |
| 83 | + pub id: i32, |
| 84 | + pub user_id: i32, |
| 85 | + pub title: String, |
| 86 | + pub body: Option<String>, |
| 87 | +} |
| 88 | + |
| 89 | +pub struct Comment { |
| 90 | + id: i32, |
| 91 | + post_id: i32, |
| 92 | + text: String, |
| 93 | +} |
| 94 | +``` |
| 95 | + |
| 96 | +Field types are allowed to differ, to whatever type is expected compatible by the corresponding crate. |
| 97 | + |
| 98 | +### `bench_trivial_query` |
| 99 | + |
| 100 | + |
| 101 | +This benchmark tests how entities from a single table are loaded. Before starting the benchmark 1, 10, 100, 1000 or 10000 entries are inserted into the `users` table. For this the `id` of the user is provided by the autoincrementing id, the `name` is set to `User {id}` and the `hair_color` is set to `Null`. An implementation of this benchmark is expected to return a list of the type `User. |
| 102 | + |
| 103 | +### `bench_medium_complex_query` |
| 104 | + |
| 105 | +This benchmark tests how entities from more than one table are loaded. Before starting the benchmark 1, 10, 1000, 10000 entries are inserted into the `users` table. For this the `id` of the user is provided by the autoincrementing id, the `name` is set to `User {id}` and the `hair_color` is set to `"black"` for even id's, to `"brown"` otherwise. An implementation of this benchmark is expected to return a list of the type `(User, Option<Post>)` so that matching pairs of `User` and `Option<Post>` are returned. Though the `posts` table is empty the corresponding implementation needs to query both tables. |
| 106 | + |
| 107 | +### `bench_insert` |
| 108 | + |
| 109 | +This benchmark tests how fast entities are inserted into the database. For this each implementation gets a size how many entries are scheduled to be inserted into the database. An implementation of this benchmark is expected to insert as many entries into the user table as the number provided by the benchmark framework. It is not required to clean up the already inserted entries at any time. Newly inserted users are generated using the following rules: `id` of the user is provided by the autoincrementing id, the `name` is set to `User {batch_id}` and the `hair_color` is set to `"hair_color"`. |
| 110 | + |
| 111 | +### `bench_loading_associations_sequentially` |
| 112 | + |
| 113 | +This benchmark tests how fast a complex set of entities is received from the database. |
| 114 | +Before starting the benchmark a large amount of data needs to be inserted into the database. The `users` table is required to contain 100 entries (or for sqlite 9 entries) based on the following rules: `id` is determined by the autoincrementing column, `name` is set to `User {batch_id}` and `hair_color` is set to `"black"` for even id's, otherwise to `"brown"`. For each entry in the `users` table, 10 entries in the `posts` table need to exist. Each entry in the `posts` table is based on the following rules: `id` is autogenerated by autoincrementing column, `title` is set to `Post {post_batch_id} for user {user_id}` where `post_batch_id` referees to number of the current post in relation to the user (so between 0 and 9), `user_id` is set to the corresponding user's id, and `body` is set to `NULL`. For each entry in the `posts` table 10 entries in the `comments` table are generated based on the following rules: |
| 115 | +`id` is set to the autoincrementing default value, `text` is set to `Comment {comment_batch_id} on post {post_id}` where `comment_batch_id` referees to the number of the current comment in relation to the post (so between 0 and 9), `post_id` is set tho the corresponding posts's id. |
| 116 | +An implementation of the benchmark is expected to return a list of the type `(User, Vec<(Post, Vec<Comment>)>)`, that contains all users wit all corresponding comments and posts grouped by their corresponding associations. |
0 commit comments