Viewing dashboard makes UI very sluggish (php)
-
For kicks and grins you can also edit /usr/local/www/javascript/index/ajax.js, go to line 32, and comment out (Put // before) all of the update<whatever>() functions.
I fixed a bug in this commit:
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/15c5b5d63710f28284a974902d0771ceefbb5e86That made most of the AJAX updates completely fail to run unless you had the CPU widget loaded.
I should probably wrap a bunch of that code in widgetActive() calls so they only run if you have those particular widgets on. As it is, it tries to update them all whether or not you have the widgets loaded.
An easy way to see if that was the problem in your case would be to go to the Aug 2 snap and add the CPU widget. If your CPU usage spikes, then it's one of those AJAX update calls doing it.
It would still be something in your configuration causing it though, as it doesn't happen either way for me, but it may still help narrow it down.</whatever>
-
So like this?
/*function updateMeters() { * url = '/getstats.php' * * new Ajax.Request(url, { * method: 'get', * onSuccess: function(transport) { * response = transport.responseText || ""; * if (response != "") * stats(transport.responseText); * } * }); * setTimeout('updateMeters()', update_interval); */}
-
Nah, like this:
function stats(x) { var values = x.split("|"); if (values.find(function(value){ if (value == 'undefined' || value == null) return true; else return false; })) return; // updateCPU(values[0]); // updateMemory(values[1]); // updateUptime(values[2]); // updateState(values[3]); // updateTemp(values[4]); // updateDateTime(values[5]); // updateInterfaceStats(values[6]); // updateInterfaces(values[7]); // updateGatewayStats(values[8]); }
-
ok, I tried that and it made no difference either before or after a reboot.
-
How about if you comment out line 19 of that same file?
// setTimeout('updateMeters()', update_interval);
That should stop all AJAX updates, not just the javascript portion.
Or you could experiment with /usr/local/www/includes/functions.inc.php in the get_stats() function to see which one of the function calls there might be causing a delay. To test in there, you need to make sure that a value is still in the variable, even if it's blank, like so:
// $stats['mem'] = mem_usage(); $stats['mem'] = 0;
-
How about if you comment out line 19 of that same file?
// setTimeout('updateMeters()', update_interval);
No change. Do I need to reboot to test it?
I will try the second part later.
-
No but you may have to clear your cache and close out of the browser. It's just javascript/ajax in that file.
-
// $stats['mem'] = mem_usage(); $stats['mem'] = 0;
I still haven't tried this one yet, but I do have some newe information.
Besides the dashboard, the Status:Interfaces page is also deadly slow to load. Each interface appears sequentially in the browser, and each one takes about 2 seconds to appear in turn.
Also on the console (serial or ssh), each modem interface takes a second or two to appear when reloading the console.
I've attached my interface information. WAN is mlppp and is a bundle of opt4 through opt10 (MODEM2-MODEM8).
-
What is the date on the snapshot you're running now?
Someone found an issue at one point last week which made some interface operations slower, and it was subsequently fixed.
-
Aug 20 snapshot is sluggish, Aug 2 snapshot is not. I'll try updating the Aug 20 slice.
-
Fixed. Thanks.