v2.0.0-Release <- Read this for performance problems #4500
Description
This was originally a PR here, but has been transformed into an issue due to being pin-able
what has been done?
We are hard at work improving Uptime Kuma.
If you want to have a look at the full set of features for v2.0, have a look here.
Most notably this includes (a full migration guide will be made before the release, dont worry):
- better performance through external MariaDB, storing heartbeats in an aggregated form, full server-side pagination for important events, better async and database usage
=> even though benchmarking is still out, we are confident that this pushes the prominent "limits" (highly hardware-dependent, not a limit imposed by us) ~500 Monitor or ~1.5GB DB-size
A large part of the focus in this release is on performance. We don't know if we are optimising for the right thing, see Can/should we addprivacy-respecting usage metrics? #4456 for a discussion on this topic.
Tip
If you are affected by the performance problems of v1, you need to reduce the amount of data you store.
The core problem is that Uptime Kuma in v1 has to do a table scan of the entire heartbeat table for some operations.
The solution boils down to having a lower amount of data => making Uptime Kuma less worried about reading those gigabytes of data.:
- reduce the retention and execute a manual cleanup via the
VACUUMbutton under/settings/monitor-history - Increase the time between checks
- pause or reduce the amount of monitors
- delete the specific history of less essential monitors (to "lower" their retention below the configured maximum)
- tightening the security via offering rootless docker images images #2086 #4052
- deprecated backup feature has been dropped (see Drop backup #3892 (comment) for an explanation why)
- deprecated cacheable lookups (not the same as
nscd) have been dropped CacheableLookup was never used for http monitors #3762 - A lot of bugfixes, some minor new features (see the milestone)
what is needed to get 2.0.0-beta.0 released
Note
We hope 2.0.0-beta.0 can be released in spring 2024, which doesn't include the e2e tests yet. During the beta test, we will try to work on implementing the e2e tests.
Tip
How can I get involved?
While most of the bugs noted below require reading some code
=> gaining some context about how the aggregated tables work, some work do not and are such better starting points:
- writing a synthetic benchmark which spawns some monitors and looks how the server handles it
- helping in writing e2e tests using playwright
- some features have not adopted to new aggregate tables yet
- Migrate existing heartbeat data into aggregate tables
- Clear stats (Update clear stats #4324)
- History retention
- Ping chart (Feat: Use
UptimeCalculatorfor PingChart #4264) -
Heartbeat table keeps 24-48 hours data only (excepted for important events, it will keep longer for the event list)(Can be deferred) - Test and fix the Badges feature (originally introduced in Add badges #1119, a big headache for us right now because the new table schemas break this feature a lot) (Fix uptime & ping badge duration #4850)
- Testing
- Drop Jest e2e testing #2174
- Playwright + Native Node Test Runner #3893
- Write more E2E Testing using Playwright
- Document how the aggregated tables work for our contributors in our contribution guide
- Migration guide from
v1tov2(Wiki) Migration Guide from v1 to v2 uptime-kuma-wiki#53- New Docker tags
- Notify about breaking changes and write a migration guide
- removed variable badges
- SMTP-templating Feature: SMTP-templating of
customBodyandcustomHeadervia liquidjs #3414- dropped support for
vArIaBlE Casedvariables - deprecated
UPPERCASEvariables (this was added to make thev1⇒v2migration more seamless, but will be removed in v3)
- dropped support for
- removed deprecations:
- Update to respect docker compose v2 #4289
- default retires is now 0 instead of 1
- Benchmark where the new performance limits are
- Write the changelog and Release
2.0.0-beta.0