Dashboard is loading slow (> 1s) #2003
Comments
Not having an SSD to run apps off of will limit the performance of any application and is likely a contributing factor to the slowness. Moving to a relational database(MariaDB/MySQL/Postgres) is also a good step to mitigate some of that. You could make use of in-memory caching using Redis instead of the default which is the database as this can lead to performance improvements especially if IOPS are a bottleneck. To use Redis add it to your Docker Compose stack as a container and add the following environment variables to you app container. |
|
Alright thank you. I have tried with redis (current docker compose at the end) but this did not make any difference, so the problem seems to be somewhere else. In theory I can live with the one second of load but I thought there might be space for optimization, especially since other applications do not have this issue (e.g dockge, uptime-kuma, mealie, portianer, gethomepage, ...). docker-compose: services:
db:
image: mariadb:latest
container_name: speedtest-tracker-db
restart: always
environment:
- MARIADB_DATABASE=speedtest_tracker
- MARIADB_USER=admin
- MARIADB_PASSWORD=${DB_PASS}
- MARIADB_RANDOM_ROOT_PASSWORD=true
volumes:
- /volume1/docker/speedtest-tracker/db:/var/lib/mysql
networks:
- speedtest-tracker
redis:
image: redis:latest
container_name: speedtest-tracker-redis
restart: always
command: redis-server --save 20 1 --loglevel warning --requirepass
password234
volumes:
- /volume1/docker/speedtest-tracker/redis:/data
networks:
- speedtest-tracker
speedtest-tracker:
container_name: speedtest-tracker
ports:
- 8081:80
- 8443:443
environment:
- PUID=1033
- PGID=65538
- TZ=Europe/Berlin
- APP_KEY=${APP_KEY}
- DB_CONNECTION=mariadb
- DB_HOST=db
- DB_PORT=3306
- DB_DATABASE=speedtest_tracker
- DB_USERNAME=admin
- DB_PASSWORD=${DB_PASS}
- SPEEDTEST_SCHEDULE=6 */2 * * *
- SPEEDTEST_SERVERS=36998,52365
- CHART_DATETIME_FORMAT= j.m. G:i
- DATETIME_FORMAT=j M Y, G:i:s
- APP_TIMEZONE=Europe/Berlin
- DISPLAY_TIMEZONE=Europe/Berlin
- APP_URL=http://speedtest.lab
- ASSET_URL=http://speedtest.lab
- ADMIN_EMAIL=${ADMIN_EMAIL}
- ADMIN_PASSWORD=${ADMIN_PASSWORD}
- CACHE_STORE=redis
- REDIS_CLIENT=phpredis
- REDIS_HOST=redis
- REDIS_PASSWORD=password234
- REDIS_PORT=6379
volumes:
- /volume1/docker/speedtest-tracker/data:/config
image: lscr.io/linuxserver/speedtest-tracker:latest
restart: unless-stopped
networks:
- speedtest-tracker
depends_on:
- db
- redis
networks:
speedtest-tracker:
external: true |
|
The other possibility is that you're running into a known Filament (the admin panel) problem where the volume of components that are registered slows down the views. They have a fix which is planned for v4 but not release date yet. |
@alexjustesen By v4, you mean v1.4 ? |
|
filamentphp/filament#9304 (comment) It's the admin panel package we use and currently it's also used for the dashboards. |
|
I see. And the same component is being used for the table in |
Correct, a "component" is a broad term in this case but the issue at the core is the same. |
|
Same Issue here, but >10s in many cases. Giving some details in case this is useful for troubleshooting. Server: Docker image of 1.2.0 on Synology 1621+ NAS I recently carried out a RAM upgrade on the NAS (from 4GB to 20GB) that gave a huge speedup for all other container based tools, but speedtest-tracker has remained slow. Stats (from homepage and synology tools) show CPU is not loaded, plenty of spare RAM, low storage load (so not convinced redis or SSD cache will significantly help) After 12 seconds the page outline is loaded, but still takes some additonal time for the graphs to appear (looks like calls to http://192.168.0.103:9080/livewire/update start after the initial page load and spend a couple of seconds waiting for server response) Dev tools gives this info for dashboard: (the element referenced is the 'next speedtest time' item) Similar slow performance is seen on the results page. Settings pages are a bit better, but still slower than expected at typically 2-3 seconds per page load. With enough clicking around, performance does seem to increase. For comparison, the homepage widget loads the API stats in much less than a second, which I think indicates the container database is performant, but I'll try a switch to MariaDB at some point soon (thanks OP) |
|
Update from my side: I switched to a SSD and moved the redis package data, the db and the container data itself to it. Still the same speeds of >1s load times... |
|
@Jannis033 how many records do you have in your DB? |
Hi, my dashboard is loading really slow. I have already looked into the other issues that are related to this kind of problem and I have also googled for it, but have not found a solution that really fixed it for me.
When accessing the Dashboard via ip (http or https) or through the reverse proxy (which has web socket header set up), the pages take over 800ms - 1500ms to load. This does not only occur after startup or the initial page load, but also after several days of uptime and when switching between pages or doing asynchronous tasks such as showing detailed speedtest results (clicking on the details button next to a result in the table). The problem was even worse before when I used sqlite (3+ seconds) but - thanks to a recommendation somewhere related to this kind of issue - I switched to MariaDB and this made it better. A ping to the web interface takes 20ms, so everything fine there, but tools like gethomepage's sitemonitor (
Services may have an optional siteMonitor property (formerly ping) that allows you to monitor the availability of a URL you chose and have the response time displayed.) show around 800ms.I have tested it on several devices in different browsers. Also, all the other containers are running as usual and have really fast (normal) response times.
What am I missing? Seems like hardly anybody else has this problem here.
I am running the container on my Synology NAS (DS423+) using Dockge. I have two WD Red Plus HDDs installed with SHR (Raid 1) and 18GB of RAM. I do not have caching SSDs. I have thought of adding a NVME SSD for caching but I cannot imaging that a simple container like this one needs some sort of ultrafast caching SSDs just for normal load times, so I am asking here for other solutions.
My docker-compose looks like this:
The text was updated successfully, but these errors were encountered: