Loading query log page takes a few hundred ms as before the upgrade.
Page load takes 6 to 7 seconds since the latest update Pi-hole FTL v6.4, Web v6.4 and Core v6.3 Released! .
When checking the filter above I notice the „all time“ is set as default, explaining why the page load takes so much time. This behavior has definitely changed. How to set the default filter to e. g. „Today“?
Before the latest release, the initial value was set to 2020-01-01, as you can see on this Github issue, but this is only applied when you select the "Query on-disk data" checkbox.
With out the checkbox, only data from the last 24h is loaded.
Indeed only the last 24 hours are loaded, giving 6.300 pages currently. The visual filter section was a „false trap“.
So the remaining question is: why does loading take so much more time compared to the initial display until the last release?
Not sure why in your case you feel this is slower.
The latest version was released with a lot of small improvements and most users are seeing the opposite effect.
If you think there is something wrong, we will need a debug log.
I don’t think, I can guarantee. Previous version made query log load within a blink of an eye (<= a second), now it takes 6 to 7 seconds. Period.
So I fear I will need to walk the debug log path which will take a while.
It’s as simple as running sudo pihole -d and selecting Y when given the upload option.
Technically yes. But unless you have changed the debug process in the last two years I will have to manually check for privacy related information first. Was way too chatty for my taste back in July 2023. So I will follow up once finished.
Just for reference: query log with 6500 pages x 10 entries on a Pi 2 loaded in appr. one second.
6 seconds loading time at minimum. No matter if accessed via http oder https.
sudo service pihole-FTL stop
sudo cp /etc/pihole/pihole-FTL.db /etc/pihole/pihole-FTL_BU.db
sudo sqlite3 /etc/pihole/pihole-FTL_BU.db "PRAGMA integrity_check;"
-> ok
sudo service pihole-FTL start
sudo pihole status
[✓] FTL is listening on port 53
[✓] UDP (IPv4)
[✓] TCP (IPv4)
[✓] UDP (IPv6)
[✓] TCP (IPv6)
[✓] Pi-hole blocking is enabled
Ah I see pihole -d is also performing an integrity check so this was not necessary in addition.
*** [ DIAGNOSING ]: Pi-hole FTL Query Database
-rw-r----- 1 pihole pihole 3,7G 14. Dez 18:53 /etc/pihole/pihole-FTL.db
[i] Checking integrity of /etc/pihole/pihole-FTL.db ... (this can take several minutes)
\ 01:03
So here’s the redacted pihole debug:
First upload (potentially failed- /usr/local/bin/pihole: Zeile 38: /etc/pihole/versions: Keine Berechtigung - as pihole almost everywhere needs a sudo since v6): https://tricorder.pi-hole.net/fCJVoQFK/ .
Second upload without any errors:
Upload successful, your token is: https://tricorder.pi-hole.net/t7MzLlg0/
@jfb pardon me for direct pinging - I was wondering if the debug log was helpful. I don’t know what’s your debug log retention time so I wanted to make sure it is not missed.
Status:
It seems that the new default behavior of the Query Log selecting “All Time” (based on the DB range) is the main cause, introduced with https://github.com/pi-hole/web/pull/3657 and shipped with Release v6.4 · pi-hole/web · GitHub .
Somehow the calculation seems to take so much longer than before this change (where no calculation took place at all, right?), rendering two CPUs with FTL on 100 % for 4 to 5 seconds and resulting in overall page load time of at least 6 seconds.
That with even only data of last 24 hours is shown, which is fine. I put my bets on the calculation, not the data fetching. Browser network analysis showed waiting for server response, not a browser/client issue, just for the records. On my system, the pihole-FTL.db is around 3.8 GB with over 76 million entries. Previously, loading the Query Log was very fast, even with the same database size.
Reworking that change would be great. A small tweak like this could make a huge difference for users with large historical logs.
Following because I’m experiencing the same issue. Takes about 10s for my query log to load in the web GUI. Query on-disk data is off.
I stopped the pihole service, removed my pihole-FTL.db since it was up to 4.6GB, and restarted the service, and the query log was near instant. However, just 24h later, it was back to taking about 10s to load. pihole-FTL.db file is up to 50MB.
Running on a raspberry pi 4 B w/ 4GB of RAM, running Raspberry Pi OS v12.12
That’s interesting, as it indicates it’s not necessarily a DB size indicated issue.
Unfortunately there was no response for two weeks now and I try to avoid directly pinging core team members - maybe they are simply on holiday.
As mentioned in my previous posts, I suspect that the named change is the cause for this. As it’s 6 seconds loading time for my Pi 5 compared to the 10 seconds on a Pi 4 it’s very likely a computational thing (Pi 4 a bit less powerful).
At this moment the ball lies in the field of the Pi-Hole team - all Information including debug logs have been provided.