|
| 1 | +PocketBase benchmarks |
| 2 | +====================================================================== |
| 3 | + |
| 4 | +This is a test PocketBase application with various benchmarks to serve |
| 5 | +as a general idea of what you could expect from a basic PocketBase instance |
| 6 | +without extra performance tuning or deployment on expensive server. |
| 7 | + |
| 8 | +- [Results](#results) |
| 9 | +- [Takeaways and things we'll have to improve](#takeaways-and-things-well-have-to-improve) |
| 10 | +- [About the benchmarks](#about-the-benchmarks) |
| 11 | + |
| 12 | + |
| 13 | +## Results |
| 14 | + |
| 15 | +- **Hetzner CAX11 (2vCPU ARM64, 4GB RAM, €3.79)** |
| 16 | + - [Pure Go results (default)](results/hetzner_cax11.md) |
| 17 | + - [CGO results](results/hetzner_cax11_cgo.md) |
| 18 | + |
| 19 | +- **Hetzner CAX41 (16vCPU ARM64, 32GB RAM, €24.49)** |
| 20 | + - [Pure Go results (default)](results/hetzner_cax41.md) |
| 21 | + - [CGO results](results/hetzner_cax41_cgo.md) |
| 22 | + |
| 23 | +- **Hop.io (1vCPU, 512MB RAM, _free tier_)** |
| 24 | + - [Pure Go results (default)](results/hop_free_tier.md) |
| 25 | + _(fails the mixed `posts50k` tests most likely a result of some resources abuse protection)_ |
| 26 | + |
| 27 | +- **Fly.io (1vCPU, 256MB RAM, _free tier_)** |
| 28 | + - [Pure Go results (default)](results/hop_free_tier.md) |
| 29 | + _(it requires swap to be configured to prevent OOM errors and restarts; fails the heavier `posts100k` tests most likely a result of some resources abuse protection)_ |
| 30 | + |
| 31 | +_Keep in mind that the tests are performed on the same machine where the PocketBase instance is deployed so the app performance can be slightly affected by the benchmarks execution itself (most hosts providers have several protections in place and at the moment I don't have the time to create proper setup to run the tests from more than one IP._ |
| 32 | + |
| 33 | +_There are several optimizations that can be done and the benchmarks will change in the future so that the tests can run as part of the development workflow to track regressions, but for now improving the overall PocketBase dev experience remains with higher priority._ |
| 34 | + |
| 35 | + |
| 36 | +#### Takeaways and things we'll have to improve |
| 37 | + |
| 38 | +- The Go and JS (_will be available with v0.17.0+_) custom routes and app hooks perform almost the same for low and medium concurrency (this is because by default we have 100 prewarmed `goja.Runtime`). |
| 39 | + |
| 40 | +- At the moment there is no much difference in terms of query execution between the lower and higher spec Hetzner VMs (_probably because most of the operations are I/O bound_). |
| 41 | + |
| 42 | +- We could experiment with different SQLite `PRAGMA` options to see if there will be any significant difference since we currently use mostly the defaults (_eg. increasing `page_size`, `cache_size`, heap limits, etc._). |
| 43 | + |
| 44 | +- The default data DB connections limit (max:120, idle:20) could be changed to be dynamic based on the running hardware to improve the overall performance and reduce the memory usage. |
| 45 | + |
| 46 | +- With higher concurrency individual query performance degrades (_probably because the runtime has to do more work, there is context switching involved, locks, etc._) but still the overall requests completion is better for most of the times. |
| 47 | + |
| 48 | +- Basic API rules don't have significant impact on the performance. The performance starts to degrade when the rule condition requires a join with a large table (especially in case of a nested relation fields lookup). Joins over large datasets are slow even for simple queries like: |
| 49 | + |
| 50 | + ```sql |
| 51 | + SELECT COUNT(DISTINCT posts10k.rowid) |
| 52 | + FROM posts10k |
| 53 | + LEFT JOIN posts100k ON posts100k.author = posts10k.author |
| 54 | + ``` |
| 55 | + Creating indexes for the relation fields can help speeding up the queries but further optimization techniques will have to be researched. |
| 56 | + |
| 57 | +- To prevent unnecessary `JOIN` statements we can implement internally a special condition that will treat single `relation` field statements like `rel.id = @request.auth.id` the same as `rel = @request.auth.id`. |
| 58 | + |
| 59 | +- The existing json column normalizations (eg. `CASE WHEN json_valid ...`) have some impact on the performance (~10%) and can be further optimized by removing them entirely and ensuring that the field values are always stored in the correct format before create/update persistence (either on app level or triggers). |
| 60 | + |
| 61 | +- The CGO driver for some queries in _large datasets_ can be ~1.5x-4x times faster. |
| 62 | + Building with `CGO_ENABLED=1` is the easiest way to boost the query performance without changing your db structure or hardware but keep in mind that it complicates the cross-compilation. |
| 63 | + |
| 64 | + |
| 65 | +## About the benchmarks |
| 66 | + |
| 67 | +The application uses the `develop` branch of PocketBase. |
| 68 | + |
| 69 | +The test database is ~180MB and has the following collections structure: |
| 70 | + |
| 71 | + |
| 72 | + |
| 73 | +In order to emulate real usage scenarios as close as possible, the tests are grouped in several categories: |
| 74 | + |
| 75 | +- **create** - Tests the write (_insert_) HTTP API performance. It is also responsible for populating the test database. |
| 76 | + |
| 77 | +- **search** - Tests the list/search (aka. `getList()`) HTTP API performance. |
| 78 | + It also contains scenarios with mixed list and update tests to observe how mixed read/write operations affects each other. |
| 79 | + |
| 80 | +- **custom** - Tests for custom Go and JS code (routes, middlewares, hooks, etc.). |
| 81 | + |
| 82 | +- **delete** - Test the delete HTTP API performance (including cascade delete). |
| 83 | + |
| 84 | + |
| 85 | +## Run the benchmarks |
| 86 | + |
| 87 | +To run the benchmarks locally or on your server, you can: |
| 88 | + |
| 89 | +0. _[Install Go 1.18+](https://go.dev/doc/install) (if you haven't already)_ |
| 90 | +1. Clone/download the repo |
| 91 | +2. Run `GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build` (_https://go.dev/doc/install/source#environment_) |
| 92 | +3. Start the created executable by running `./app serve`. |
| 93 | +4. Navigate to `http:localhost:8090/benchmarks` |
| 94 | +
|
| 95 | +_By default all tests are executed in the previously mentioned test categories order, but you can also |
| 96 | +specify which exact tests to run using the `/benchmarks?run=custom,delete` query parameter._ |
| 97 | +
|
| 98 | +The above will start the benchmarks in a new goroutine and once completed it will print its result to the terminal and in the `benchmarks` collection |
| 99 | +(_note that some of the tests are slow and it may take some time to complete; we write the test result as a collection record to workaround various host providers DDoS protections and restrictions like persistent connections limit, read/write timeouts, etc._). |
0 commit comments