Viewing dashboard makes UI very sluggish (php)

[jimp]

I doubt it's helping anything. :-)

[clarknova]

ok. I left it on after reading this post, but if it's not doing anything for me then I'll shut it off tonight.

http://forum.pfsense.org/index.php/topic,26903.msg140173.html#msg140173

[clarknova]

ok, this is definitely something in the later snapshots, and it's affecting the nanobsd platform too. And it's not my config.

I backed up my config from the full install on Atom hardware and uploaded it to a net5501 running nanobsd 2g. When I boot the slice using the August 2 snapshot and load the dashboard, top shows 1.95% php CPU. When I boot the Aug 20 slice php again hogs all the idle cpu.

[jimp]

I updated to a snap from this morning on amd64 and it's still sitting practically idle.

How can you say it's not in your config when you restored your config to the other router? Sure, the slices were different but your config is still the common element.

Try it with a fresh config, not a restore. See if the same thing happens.

[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.