Web GUI responsiveness
-
Logging in is nearly instantaneous. Bouncing from tab to tab is also very fast, nothing seems to take more than a half-second. That said, there seems to be about a 5-second delay (waiting for router.domain message) to apply any change.
Even something that is not parsed like the description in a DHCP reservation.
This is completely livable, but because the delay is so consistent no matter what I change, I am wondering if there is a reason and perhaps even something I can do about it.
Does everyone experience this delay?
PS CPU is a quad Xeon, virtually asleep from a consumption perspective, and the delay is about the same when the link is idle or when busy.
-
Do you have auto config-backup enabled? Is it enabled correctly?
You can see a big delay on any change while it tries to backup if not.
Steve
-
It is enabled it seems to be configured properly. I can try with it disabused. Is My experience ubiquitous or do some experience near instantaneous saves.
-
I did a manual auto backup, and it succeeded and took approx 4-5 secs.
-
Disabled the auto backup, no change to how long it takes to save / apply.
-
Drive spinning down between writes maybe? I would expect it to be quicker than that.
Steve
-
@stephenw10
Thank you for confirming. at least now I know its something I can poke at when I have time.
I run this system off an SSD, so I doubt it is drive sleep related.
Also it's every time, even if I make 5 changes in a row. -
Hmm, check the timing in the system logs. What's taking the time?
-
stripped out packages I was not using, left only RRD summery and open VPN expert pcks
installed today's 2.5 build
disabled ACB
-still takes between 4-5 secs to apply changessystem log - OS boot
only thing I saw there that that stuck out was
mlx5en: Mellanox Ethernet driver 3.5.2 (sept 2019)
this was strange as I don't have a mellanox NIC in there now, only intel NICs. I may have at one time but ...system general
only errors since boot were a couple
(I was editing a description in a DHCP reservation)
Aug 10 19:31:39 dhcpleases 92038 Could not deliver signal HUP to process 63264: No such process.
Aug 10 19:31:32 check_reload_status 593 Syncing firewall -
@mervincm said in Web GUI responsiveness:
Could not deliver signal HUP to process 63264: No such proces
The process dhcpleass 'hups' one process : unbound, the resolver. It does so when a new DHCP lease come in.
It reads unbound's pid file (if it exists), and when found, it uses the int (= process number) to hup unbound.
Which, in this very moment, was already instructed to restart by "some one else'.Just to be sure : the DNS log mention a lot of unbound restarts (stop + start) ?
-
The Mellanox drive line is expected on any system.
The dhcp leases line it likely something attempting to restart it twice (still starting from the last previous time).
Here's me editing an alias on a test box:
Aug 11 12:06:27 check_reload_status Syncing firewall Aug 11 12:06:39 check_reload_status Reloading filter Aug 11 12:06:40 xinetd 23110 Starting reconfiguration Aug 11 12:06:40 xinetd 23110 Swapping defaults Aug 11 12:06:40 xinetd 23110 readjusting service 19000-tcp Aug 11 12:06:40 xinetd 23110 Reconfigured: new=0 old=1 dropped=0 (services)It responds pretty much instantly in the GUI. The first log line is when it hit save. The second log line is when I hit apply. It takes ~1s to reload everything.
Now that's a test device without much config on it. As you add more services and more rules, and tables etc it takes longer to reload.Steve