WebGUI Lag
-
I've noticed a bunch of times lately where my webGUI will lag when I go in an out of settings. It mainly happens when I make changes to interfaces like OpenVPN client/server along with other settings. I figured when I would make certain changes and an interface has to be reset it would drop for a few seconds but it seems like it's happening very frequently now.
I'm running pfSense 2.4.5 on an AMD Eypc 3000 8-core CPU and 32GB of ram, it was re-purposed.
-
System > Update > Update Settings > Disable the Dashboard auto-update check
and try again.-Rico
-
Thanks for the suggestion, I just made the change and I will update the forum based on my coming experiences.
-
If found that if I start or stop and OpenVPN client on the pfSense all communication to the pfSense hangs for 20-30 seconds. I wasn't sure if that an interface being dropped and need to come back up or another issue.
My assumption was that because I restarting a VPN client service it wouldn't affect my connection because I am connected into the LAN network.
-
@Rico, I'm started to notice a really large lag when going to Status/DHCP Leases. The last time I clicked on it, it took about 60 seconds to load. I have 5VLANs, and total about 30-40 devices across all of those.
I wanted to see if you had any other thoughts.
-
@cyrus104 said in WebGUI Lag:
notice a really large lag when going to Status/DHCP Leases.
You mean this page :
That page reads the /var/dhcpd/var/db/dhcpd.leases file, parses it, and spits out the the page.
Nothing more - no fancy stuff.
If that page is slow, it's your entire system that is crawling .....Restarting " VPN client service" will do something with interfaces.
When interfaces are modified, all services that are 'bound' to inetraces are getting restarted.
Among these is unbound, the resolver (just an exemple).
Guess what : it's quiet popular these days to make unbound as slow as possible.Test for your : open the Status > System Logs > System > DNS Resolver page.
Take note of the most recent log line.
Keep this windows open, use another pfSense GUI access windows to restart your VPN client.Now, refresh your DNS resolver log page.
Did it resort ?
How long did it take ?Difference between :
Apr 9 16:04:41 unbound 18315:0 info: service stopped (unbound 1.9.6).and
Apr 9 16:04:44 unbound 72602:0 info: start of service (unbound 1.9.6).Which means : 3 seconds of no DNS on the network. IMHO, That's already very long.
Check also other services - see other logs.
-
@Gertjan thanks a ton for the response.
Yep that's the window that sometimes take a long long time to load.
So when the I bounce the VPN service it restarts the services attached to those interfaces... makes sense.
I hope your comment here is laced with sarcasm, I would hope that we would want anything to be slow.
@Gertjan said in WebGUI Lag:Guess what : it's quiet popular these days to make unbound as slow as possible.
I restarted the ovpn service, this time it didn't take long at all. I'm not sure why it was faster and didn't cause the GUI to lag.
Apr 9 22:41:24 unbound 39186 [39186:0] info: service stopped (unbound 1.9.6).Apr 9 22:41:25 unbound 39186 [39186:0] info: start of service (unbound 1.9.6).Looks like it was pretty quick. In between these 2 messages were server stats messages for 16 threads (guessing it's 16 because of how many hardware threads this system has). But otherwise this restart seemed fine.
I'll keep my eye on the logs anytime I see a noticeable slow down.
Next up, working on my DNS Resolver Slowness but I think that's more of a routing over a VPN issue.
Thanks again for some tips on where to look and reasonable times.
-
One second for an unbound restart is ok.
Btw : why would you need to restart a service like OpenVPN ??
Still, I can't find an explanation why a page like Status > DHCP Lease would be slow to shhow up. All it does is shwing afile that already exists. It should be one of the fastest page on the system to show.
You can use your browser to measure the load time of a page, and show you details of each part of that page.
edit : Firefox : hit Ctrl-Shift-I and have a look at "Perfomance" and "Network" while (re) roading the page.Are you using a VM or running pfSense on a dedicated device ?
@cyrus104 said in WebGUI Lag:
laced with sarcasm
Noop. Just another way of saying : loading up pfBlockerNG with dozens or more lists, thus thousands of domains to enter into the local cache, which will slow down unbound during startup.
-
I'm live in the US and don't run a VPN unless it's for work, fun, or sketchy network. Right now I'm living overseas in Thailand, it's not very restrictive but I have a lot of US websites that won't let me login... to manage my finances and pay my bills (Of course there is always the streaming issue but I'm less concerned with that). So it's less of a trust issue and more of a general locality one.
The network over here is slow and I have 2 VPN endpoints that perform very differently throughout the day. I've tested Express, Nord, rolling my own in AWS. It seems to be an issue with the local internet, I eventually start to get a lot of dropped packets (up to 20-30 percent). The VPN will bounce itself, during this time downloads make it worse. Most of the time I can switch VPN endpoints to another local and it will leave the country on a different more stable path.
None of this was an issue until COVID-19, so I think it's stress on the ingress/egress points for the country.
When the network is bad, the vpn can drop several times back to back which plays hell with the GUI lag due to services being restarted.
pfSense is running on a dedicated box. Supermicro AMD Eypc 8c/16t, 64GB ram, Samsung 970 Pro NVMe, built in Intel 10Gb nics. Yes, I believe it's a little overkill but it's a repurposed box that I was going to use for something else.
When it was really bad this is all I got:
I could not stop and refresh the page, I had to click on the Dashboard and then go back to it and it still took 30-40 seconds.Here is the full section from when I was on the Dashboard and clicked on the DHCP Lease.
Right now I am using the primary lists that came with pfBlockerNG plus a few, I don't think I went crazy with rules. I was using a Pi-Hole but figured it would be nice to have everything centrally managed.
-
I don't understand why your browser POST's tons of things against the dashboard page.
Again, visit the DHCP Leases page.
Open the web dev tools.
Hit F5 to (re)load the page - or better, Ctrl-F5 to skip loading from cache.
No references to other page for me.
Also : Are you using curicata ? Is it still active ? Browser trying to load file that do not exists become very slow.
-
The Dashboard, I can explain. Here is what I have turned on:
Sys Info
Gateways
Interfaces
OpenVPN
pfBlockerNG
Traffic Graph Only with the VPN and WAN (everything else is turned off)
Services Status
Interface Statistics
DDNS Status
NTP StatusI turned on a decent number of things to see what was useful, so far I've been looking at most of it but the Interface Statistics.
When I use Ctrl-F5 I am getting 23 requests and 30-50 s to finish.
I don't see suricata in the services list as running. I see that it's installed but not sure what package installed it, is it being used by pfBlockerNG?
-
@cyrus104 said in WebGUI Lag:
The Dashboard, I can explain. Here is what I have turned on:
Sys Info
Gateways
Interfaces
OpenVPN
pfBlockerNG
Traffic Graph Only with the VPN and WAN (everything else is turned off)
Services Status
Interface Statistics
DDNS Status
NTP StatusI turned on a decent number of things to see what was useful, so far I've been looking at most of it but the Interface Statistics.
When I use Ctrl-F5 I am getting 23 requests and 30-50 s to finish.
I don't see suricata in the services list as running. I see that it's installed but not sure what package installed it, is it being used by pfBlockerNG?
Suricata is installed by no other package and it sure can't install itself. It can only get there by being installed by an admin user on the firewall. The only other remote possibility is it was installed once long ago and removed, but then someone restored an old config from that prior time period to the firewall (and thus would bring Suricata back from the dead, so to speak).
The particular file complained about in the browser debug screen (
suricataupdateDelay) is part of the Suricata Alerts Widget. That code should all be removed when the package is removed, and it should not be referenced whenever the Alerts widget is not enabled. -
Great.
@bmeeks just defined zombie packages. -
Not zombies!!!! Well I did restore this config from awhile ago but I didn't even think I had it active on the last build. Regardless, I went ahead and removed it unless I come up with a reason to use it and then I reinstall it and hopefully that will fix anything broken by an initial misconfiguration.
So far it's loading in about 5-8 seconds. I'll continue to check on it while troubleshooting other issues.
Thanks.
