https://tricorder.pi-hole.net/qh3mvLs5/
After updating from 5.x to 6.0, I have noticed very long response times for the web frontend.
Loading the dashboard or other subpages takes a long time of 10 seconds or more.
Ps.: lighttpd was uninstalled during upgrade
Ps2.: pihole6 is running in a LXC-Container on Proxmox with 256MB RAM
Ps3: using http://192.168.3.14:8080/admin runs really fast
Ps4: using http://192.168.3.14:8080/admin also runs in hick ups
I installed completely new on Proxmox VM with Debian 12 to exclude upgrade issues.
But http://192.168.2.14/admin is also very slow.
Here is my brand new, not customized configuration
https://tricorder.pi-hole.net/6xn2sOMs/
Same here. I don't know whether it's because I'm using an old RBP which cannot cope with the changes, but I had to reboot the RPB because it's become unresponsive. Moreover, it occasionally spikes to over 100% CPU and memory.
This is my debug token: https://tricorder.pi-hole.net/GgH8ShWz/
I also get an error when tryign to delete a group (" Could not remove entries from table
FOREIGN KEY constraint failed"), but that's a separate issue ...
I have another suspicion...
In the PiHole configuration, the hostname Pi.hole is set.
I have two virtual machines running PiHole (one 5.x and one 6.0).
They both have this default name. Maybe that triggers some kind of routing conflict?
But then I'm surprised that using the IP instead of the domain name in the URL doesn't improve performance either
Of course I added my FQDN to the configuration.
But that led to a certificate error with Pihole6, so I reset it to the standard.
I don't like this indirect compulsion to use the standard name at all.
I have read about issues with large Blocking Lists during the Pi-Hole v6 Beta period when using less than 1 GB of RAM so please adjust the RAM amount for your Proxmox VM/LXC and see if it helps 
For those using Raspberry Pi older than the 3B generation : It's time to upgrade! 
The only thing that the pi.hole part will cause is randomly accessing one of both Pi-Hole instances so I would not worry about that since you can just use the IP address to access them
Same here. Running Pi-hole in an LXC on Proxmox. Upgraded from version 5.
Web Developer Tools show interestingly almost exactly 29 seconds when changing from one menu item/page to another. 
My LXC is running with 1 CPU, 512 MB RAM and 8 GB SSD space.
Will try what happens when I upgrade to 1 GB RAM ...
Sounds like my RBP is virtually unsupported, so I might downgrade Pi-hole rather than throwing it away ...
H/W path Device Class Description
========================================
system Raspberry Pi Model B Rev 2
/0 bus Motherboard
/0/0 processor cpu
/0/1 memory 429MiB System memory
/1 usb1 bus DWC OTG Controller
/1/1 bus USB hub
/1/1/1 eth0 network Ethernet interface
You could lower your VRAM to just 16 MB for a bit more free RAM if you want : 512 - 429 = 83 MB in use I think
I'm in the same boat when I upgraded my 2x updated Debian 12 LXCs from Pihole v5 to v6 this morning. Very slow responses on the gui over both 80 and 443.
Both Proxmox LXCs have way more resources than they need - 2x cores, 4Gb RAM and 8Gb of storage.
https://tricorder.pi-hole.net/QeA6WHvu/
and
https://tricorder.pi-hole.net/rKqwWWvy/
Happy to provide more info if it would help someone.
Just an information:
I'm running Pi-hole v6 in a docker container in a Pi 3B+ for months and never noticed a memory issue.
Pi-hole, actually gravity, always had issues in lower end devices if the user adds too many large lists, but I never had issues testing containers (sometimes 2 or 3 running at the same time) in a 3B+.
We are investigating what could be the cause of the slowness. Most users are not seeing slowness if http is used to access.
That's true: performance using plain http is not significantly worse.
Also, aside from occasional peaks both CPU and memory usage are acceptable once the RBP settles down (memory is usage now ~30% for me).
What I am posting is just what I picked up from @DL6ER I think in one of the Beta related Topics over the last few weeks so I hope I have remembered it correctly
Faster loading times when not using HTTPS/SSL sounds pretty much logical since it requires more resources in general so I wouldn't worry much about that part.
