v2.0.0-Release <- Read this for performance problems
#4500
Comments
CommanderStorm
added
the
area:core
This comment was marked as resolved.
This comment was marked as resolved.
|
@compgeniuses If you want to test-drive or contribute one of the areas named above, our contribution guide should have all the answers. If you are missing something for development, feel free to ping me. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as duplicate.
This comment was marked as duplicate.
|
See top of this post, the tasklist progress is at 5/17 so still a lot of work todo. This is FOSS so to help speed up improvements, you can contribute in different areas as per your level of expertise. It has been explained several times that no ETA can be given depending on the contributions of the community mainly. |
Not even that, have commented somethng similar why we won't give out ETAs multiple times in this thread..
That is somewhat misleading.
literally any help is appreciated. |
just to be clear, as i assume this is the best mitigation: after setting a lower number of retention days, for manual cleanup you intend a "clear full statistic" or "shrink database"? so the retention days are not applied to the previous stored datas? |
|
Cleanup = the |
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):
=> 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 add
privacy-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
v1has 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.:
VACUUMbutton under/settings/monitor-historynscd) have been dropped CacheableLookup was never used for http monitors #3762what is needed to get
2.0.0-beta.0releasedNote
We hope
2.0.0-beta.0can 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:
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)v1tov2(Wiki) Migration Guide from v1 to v2 uptime-kuma-wiki#53customBodyandcustomHeadervia liquidjs #3414vArIaBlE CasedvariablesUPPERCASEvariables (this was added to make thev1⇒v2migration more seamless, but will be removed in v3)2.0.0-beta.0The text was updated successfully, but these errors were encountered: