Closed garanda21 closed 1 year ago
@garanda21 can you log into your container's terminal and run php artisan optimize
? This will refresh the application cache which can improve performance
php artisan optimize
Done, result:
INFO Caching the framework bootstrap files.
config ................................................................................. 134ms DONE
routes ................................................................................. 43ms DONE
But there's no much difference, here is the docker config that I'm using:
docker run -d --name speedtest-tracker \
-p 8443:443 \
-e PUID=1000 \
-e PGID=1000 \
-v /path/to/directory:/config \
-v /path/to/directory/certs:/etc/ssl/web\
ghcr.io/alexjustesen/speedtest-tracker:latest
Not strange commands or anything else on boot.
I'm trying to test with SSL_MODE=off
or SSL_MODE=mixed
, but is not possible to use only port 80, the application always redirect to https no matter what, adicional every time that I change SSL_MODE, the log shows this error: nginx: [emerg] a duplicate default server for 0.0.0.0:80 in /etc/nginx/site-opts.d/http.conf:1
and nothing works, I have to recreate the container.
The UI is very slow for me too, when I click on the "results" tab it takes anything from 15 - 30 sec to load.
Already tried php artisan optimize
, no noticable difference tho.
Here's my docker-compose.yml (changed volume mapping path and port):
version: '3.3'
services:
speedtest-tracker:
container_name: speedtest-tracker
ports:
- '<port>:443'
environment:
- PUID=1000
- PGID=1000
volumes:
- '/path/to/config:/config'
restart: unless-stopped
image: 'ghcr.io/alexjustesen/speedtest-tracker:latest'
can you describe the hw platform? rpi?
No, it's an Intel NUC 7 i5 (BLKNUC7i5DNHE). I run all my docker containers on this thing, speedtest-tracker is the only one being that slow.
In the next release I'm going to add some additional debugging tools to see if we can narrow down what's causing the performance issues. Hold tight for a couple days.
Hey there, just wanted to check back for those debugging tools you were talking about. Is any of that implemented yet? Still having major performance issues on the "results" tab, sometimes even running into timeouts especially when showing more than the default 10 lines per page.
@mztiq and @garanda21 I forgot to ask, what kind of DB are you using?
@mztiq and @garanda21 I forgot to ask, what kind of DB are you using?
My case is sqlite, mapped folder to "database.sqlite"
@mztiq and @garanda21 I forgot to ask, what kind of DB are you using?
I'm using sqlite too.
@mztiq and @garanda21 I forgot to ask, what kind of DB are you using?
I'm using sqlite too.
Both on rpi's too right? If so which ones
Mine is dockerized on Synology NAS DSM7 DS218+
@mztiq and @garanda21 I forgot to ask, what kind of DB are you using?
I'm using sqlite too.
Both on rpi's too right? If so which ones
No, it's an Intel NUC 7 i5 (BLKNUC7i5DNHE).
I run all my docker containers on this thing, speedtest-tracker is the only one being that slow.
see my comments above for more information like docker-compose.yml
if needed.
Would you guys be up for testing a different database instead of sqlite?
Would you guys be up for testing a different database instead of sqlite?
Sorry for the late reply, of course I'm up for some testing, just deployed with MariaDB/MySQL. Give me some time to report back, first I need to collect some speedtest results (since for me only the "Results" tab was slow when showing lots of results).
Just tested again and I have a feeling that performance got noticably better, not sure if it's related to changing the database or updating to v0.8.0 which happened around the same time.
From Logging in to seeing the dashboard it takes around 5 seconds. Switching to the "Results" tab takes around 5 seconds too. Switching to 50 results per page and browsing though the pages takes 4-5 seconds too.
It's still not "instant" and super fast but I guess one can live with that slight delay (compared to the 20-30 seconds delay I initially had).
Thanks again for your work and the productive weekend you had :).
Just deploy with MySQL, first time load take some time and “first” click on any option on left menu takes too long. After this first click loading times are reduced significantly.
Are you guys using docker compose? I'm starting to think this is filesystem related and we might be able to move the cache into memcached, redis or the database.
Since it's build on the Laravel framework we can plug into any of the 1st party solutions. https://laravel.com/docs/9.x/cache#main-content
Yes, I'm using docker-compose with the docker-compose.yml
from your docs (Docker MariaDB/MySQL). I'm up for further testing if you have anything you want me to test.
Let's add a caching system other than the default filesystem. Let's try memcached first, docker-compose details below...
First add depends on config
to the app container
depends_on:
- memcached
Next include the memcached image
memcached:
image: 'memcached:alpine'
ports:
- '11211:11211'
networks:
- networknamehereifyouhaveone
Lastly add in the .env
file change the CACHE_DRIVER
to memcached
and a new variable for the memcached host MEMCACHED_HOST=memcached
.
Not using a .env
yet, can I just create it or do I have to declare it somehow in the docker-compose.yml
? Not 100% sure about that.
I can test in like 1 hour and will get back to you.
The app will have created one for you in the mounted volumes.
Let's add a caching system other than the default filesystem. Let's try memcached first, docker-compose details below...
First add
depends on config
to the app containerdepends_on: - memcached
Next include the memcached image
memcached: image: 'memcached:alpine' ports: - '11211:11211' networks: - networknamehereifyouhaveone
Lastly add in the
.env
file change theCACHE_DRIVER
tomemcached
and a new variable for the memcached hostMEMCACHED_HOST=memcached
.
After make all changes, I got this error on log:
[2022-12-19 14:02:06] production.ERROR: Class "Memcached" not found {"exception":"[object] (Error(code: 0): Class \"Memcached\" not found at /var/www/html/vendor/laravel/framework/src/Illuminate/Cache/MemcachedConnector.php:69) [stacktrace] In MemcachedConnector.php line 69: Class "Memcached" not found
Any thoughts ?
You're going to need to specify where the memcached container is using the MEMCACHED_HOST
env var. If it's not in the name network as your app container put it's IP address and port for the host.
You're going to need to specify where the memcached container is using the
MEMCACHED_HOST
env var. If it's not in the name network as your app container put it's IP address and port for the host.
Not working for me, is there any way to check if php extension is loaded:
extension=memcached.so
Can't get it to work either, same error.
In MemcachedConnector.php line 69:
Class "Memcached" not found
s6-rc: warning: unable to start service startup: command exited 1
/run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all the services up! Check your logs (in /run/uncaught-logs/current if you have in-container logging) for more information.
prog: fatal: stopping the container.
[19-Dec-2022 14:50:22] NOTICE: Terminating ...
[19-Dec-2022 14:50:22] NOTICE: exiting, bye-bye!
I tried without a docker-network and MEMCACHED_HOST=<HOST_IP_ADDRESS>:11211
in the .env
and with adding a docker-network to all containers (App, DB, memcached) and MEMCACHED_HOST=memcached
in the .env
.
In the next release I'm going to introduce a database cache pattern, let's skip memcached for the time being and we'll circle back around to it should this other option not work.
@garanda21 #296 introduces support for database cache which will be released in v0.10.0. Once that version is released (hopefully later tonight) let me know if this resolves your issue with slowness.
That's great news, can't wait to test it too (going to take a while though, my little NUC died yesterday and I'm still working on replacing it)
I saw a pretty drastic improvement event enabling it on wsl so it should be a significant improvement over the file driver
This should work with sqlite ? or just mysql/postgres?
Should work with all 3
Just as a small heads-up from my side: I replaced my old NUC (NUC7i5) with a much more powerful one (NUC10i7) since the old one died.
The general delay of the UI I noticed disappeared, just the results tab is still quite slow when I choose "show all".
Overall UI performance increased drastically with my new NUC, so I'm not sure how useful I'll be for performance tests in v0.10.0.
Just as a small heads-up from my side: I replaced my old NUC (NUC7i5) with a much more powerful one (NUC10i7) since the old one died.
The general delay of the UI I noticed disappeared, just the results tab is still quite slow when I choose "show all".
Overall UI performance increased drastically with my new NUC, so I'm not sure how useful I'll be for performance tests in v0.10.0.
Yeah I'd avoid selecting "show all" that's going to be pretty slow
This seems to be generally resolved so closing out the issue to keep the backlog clean 🧹
Im new and I see the slow UI, on a RPI 4
I see the slow UI, on a RPI 4
Me too.
//cc @alexjustesen
Describe the bug From login, to navigate on web application, every click takes to many seconds. Maybe duplicate from issue #92, but he behaviour is exactly the same, loads up to 20 seconds.
To Reproduce Steps to reproduce the behavior:
Expected behavior Faster load on ms. Actually is taking up to 18 seconds to load some pages
Environment (please complete the following information):
Screenshots Login screen:
Dashboard:
Logs
Console:
Additional context I'm using docker with sqlite. Mapped config file and accessing trough mi local IP and HTTPS.