Viewing dashboard makes UI very sluggish (php)

clarknova

Both slices use the same config. Same hardware, same config. Once slice loads shows 100% CPU usage while viewing the dashboard, the older slice shows 1.95%. The only changed variable is the snapshot.

azzido

Try removing all widgets from dashboard and adding them back one by one. Maybe that will help to pinpoint which one of them is causing the issue or if it's the dashboard itself.

clarknova

I removed every widget from the dashboard and it was still sluggish. I don't recall if I then tried saving, navigating away, and then back. Will do so tonight or Monday morning when I load up the other slice.

jimp

That still doesn't remove something in your config from being part of the issue. Try it again with both slices and a stock configuration first. Or at least a bare minimum configuration to operate.

clarknova

At best it's an interaction between the software and my config. The same config doesn't cause the older snaps to malfunction.

I will try a stock config and let you know what I find.

jimp

Or, quite possibly, something was enabled but broken in an older snapshot but works now :-)

Either was it is a valid and necessary test to help narrow down the problem.

jimp

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/15c5b5d63710f28284a974902d0771ceefbb5e86

That 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>

clarknova

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);
 */}

jimp

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]);
}

clarknova

ok, I tried that and it made no difference either before or after a reboot.

jimp

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;

clarknova

@jimp:

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.

jimp

No but you may have to clear your cache and close out of the browser. It's just javascript/ajax in that file.

clarknova

@jimp:


	// $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).

interfaces-config-pfsense.burgess-20100830072450.xml.txt

jimp

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.

clarknova

Aug 20 snapshot is sluggish, Aug 2 snapshot is not. I'll try updating the Aug 20 slice.

clarknova

Fixed. Thanks.