Is the dashboard loading the entire history of heartbeat?
Lanhild opened this issue · comments
📑 I have found these related issues/pull requests
In v1, 500+ [monitors] (depending what "+" means) is likely pushing it.
#4094 (comment)
🛡️ Security Policy
- I agree to have read this project Security Policy
Description
My Uptime Kuma DB is 10.73 GB. While I understand this might create slowness, I don't think this is where the issue comes from.
That's where my question comes from: Does the dashboard load the entire history of heartbeat?
With this comes another one. I've often found in the repo issues being mentionned that ~~350 to "500+" (see issue #4094) monitors is where issues arise.
In my case, I have 114 monitors, all of type HTTP so I'm nowhere near the 500+ number. Out of the 114 monitors, about 50 of them are pinging the index page of websites. Could the size of the payload returned by every ping affect performance?
My CPU and RAM usage always are below 40% usage.
👟 Reproduction steps
- Install Uptime Kuma
- Use it for a while with a bunch of monitors
- Slowness happens after a while when loading the dashboard page
👀 Expected behavior
My suggestion (if possible at all) is to load the heartbeats of a monitor only when the user clicks on it.
Stop showing the hearbeats on the sidebar, while still showing if the monitor is alive/dead.
Heartbeats would only be shown when clicking on the specific monitor
😓 Actual Behavior
Often times very slow loading times of ~~ 30 seconds to view the dashboard. While waiting for the page to load, the dashboard appears as if there are no monitors.
🐻 Uptime-Kuma Version
1.23.11
💻 Operating System and Arch
Ubuntu 22.04
🌐 Browser
124.0.6367.60
🖥️ Deployment Environment
- Runtime: Cloudron/Docker
- Database: SQLite
- Filesystem used to store the database on: on a VPS's SSD
- number of monitors: 114
📝 Relevant log output
No response
We have implemented something similar already, but are still working out some kinks of different improvements (see #4500):
Your storage might be much better than what normal people are running
=> this is why you can push this much farther than what our "documented" performance limits are.
=> I would recommend you to reduce your retention.
Please see #4500
better performance through external MariaDB, storing heartbeats in an aggregated form, full server-side pagination for important events
=> 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 #4456 for a discussion on this topic.