WebGUI performance related to password hash strength - improved WebGUI speed by lowering hash. Why?
-
As every web page, before you see it, it has to be build first. The web engin will be fast, but it has to ask PHP first to do building first.
So, for every widgets, "loads" of info needs to be collected. Using world's slowest interpreted language : PHP.Have a look at these : /usr/local/www/widgets/widgets/ and one level up /usr/local/www/widgets, and you get the idea ^^
So, imho, there are two real solution :
Throw big intel iron at it.
Or keep only the bear minimum number of widgets activated. All the info can be found under the Status menu or else where anyway. -
@w0w I'm sure there are a lot of optimizations that could help speed up Dashboard load times. Now that I've got a working XDebug setup and some familiarity with debugging this, I might try to attack some of the worst offenders.
Without even having looked, I'd bet my money that widgets each source their own includes and re-run functions like enumerating interfaces, fetching gateway status, services status etc which could be "expensive". Storing and fetching this data from a global namespace could speed these up and avoid redundant calls.
-
The dashboard could really benefit from some caching. It really isn't necessary to go out and scrape the dozens of commands required to construct even the default dashboard layout ... on every load of the dashboard. Even something like a daemon that runs adjacent to PHP that periodically does this data collection and then serves up a json feed for the dashboard to consume would eliminate the blocking effect of the current "architecture".
Need help fast? https://www.netgate.com/support
-
@cmcdonald said in WebGUI performance related to password hash strength - improved WebGUI speed by lowering hash. Why?:
The dashboard could really benefit from some caching
Afaik, some widgets, like the current state of the installed packages, and avaible packages, is actually already cached.
but other info, like "DHCP Leases" or "Firewall logs" : should these be cached and regenerated all the time - and even when the dashboard isn't shown ? This will mean that billions of CPU cycles will get burned for nothing , for ... 99 % of the time, the info will never be showed, as very few of us keep the dashboard page open all the time.
And the moment you visit it, it wouldn't be fresh info, but something like "59 seconds old", so you have to wait 59 seconds for the info to be fresh .... so you still have to wait ab random time, between zero and 60 seconds - if that is the cache refresh time.
Faster then 60 seconds and you really start to burn performance 'for nothing'.
Ok, a cache refresh 5 minutes then ? Then the info you'll see is 150 seconds old as an average (2,5 minutes). It could be very recent, it could be close to 5 minutes old.
Who wants that ?Visiting the dashboard is like ordering a burger. You want the fresh one, or the one that was pre fabricated because the local computer told the burger-builder to pre bake one ? ^^
I'm not sure if caching will make things going any faster. It I'm sure it will "cost" a lot.
And what is it worth as the dashboard page shows up fast, with knowingly outdated data ? You still have to wait.
People want info fast, and they don't cares if its not life, valid, actual info ?!
I prepare to wait a bit, for current info.
That's why I proposed : throw a Xeon at it.
Or show a progress page builder, or a nice video, while we're waiting
-
@Gertjan I agree that we don't want to cache data that "might" be used. I have a slow 2100 and I am looking for faster page loading in general. I login when I need to do something. I'm rarely interested in the dashboard. I would vote for a general setup checkbox that I could uncheck, and not get the dashboard when I login. Then I can login faster and just select from the menus what I want to do.
-
@fabnavigator Just to say it, widgets can be removed from the dashboard. Do collapsed widgets update? I would think not, and that could be close to your request...just collapse them all...the minus sign icon, then the floppy disk/Save up top.
-
@SteveITS It's not the same. When I want to see what is going on, I want to see it all (or a bunch of it at least). If it wasn't the default page, and affecting my login time, I would have more widgets selected than I do now.
-
I would also prefer the widgets to stay — sometimes it’s more convenient to analyze events that way. I’d also be fine if, instead of the dashboard, it showed something like “updating,” but the top menu bar was always accessible, so after logging in you could immediately navigate where needed. I’m not sure… I haven’t really dug into the dashboard logic yet. I don’t know if that’s even possible, or more importantly, whether it’s necessary at all.
-
@cmcdonald
Dashboard must alive asynchronously from a system.
Load immediately, maybe show some update in progress indicators, and start to show realtime outputs when every data source will wake-up.
That’s how UI (and UX) are working for last couple decades
-
I've managed to get a very fast pfSense dashboard.
The pfSense login screen always shows up very fast.
After entering 'admin' and the password that comes with it, and hitting "Sign in", the dashboard shows up in ... less then half a second :
I know, silly.
This, for me, proofs that the dashboard will be slower if it has more to do.
So, it's the method used to collect and show the data.
With some smart JavaScript coding, the dashboard 'frame work' could show up way faster, initially with empty frames of course and they will fill up one after the other when the info become avaible.
The data won't show any faster, but our eyes are occupied with moving stuff on the screen, as widgets get filled in with data, so the wait become more bearable.
A psychological solution ^^ -
If you want to keep talking about the Dashboard, let's move that chatter to another thread and keep this one just about the original password check problem.
-
W w0w referenced this topic
-
-
G Gertjan referenced this topic
