[solved] WebGUI slow to make config changes after configuration restore

ljorgensen

Hi,

I've googled about and found this to be a problem on nanoBSD platforms, but I experience it on a full install and can't find any help on it.

WebGUI is snappy as long as I don't change anything. If i create a rule or alias, save a rule or alias, or apply changes, it takes about 20 seconds to respond. I think this happened when I upgraded to 2.3.3. The box in question is in a HA setup and has many rules and interfaces.

I may be completely out on a limb here, but could it have anything to do with RRD data being stored in config.xml? Are they compressed and encoded every time I make a configuration change? config.xml is about 6 MB.

SOLUTION: The configuration retained 6MB of RRD data that should have been removed after it was restored on a new box. Removed it manually with viconfig.

Lars

jahonix

@ljorgensen:

config.xml is about 6 MB.

With or without traffic data?

It could help potentially if you give a hint on your system, e.g. CPU, Ram and storage.
I expereience this on ALIX and APU1 systems but I expect it due to limited resources.

doktornotor

Are you using the AutoConfigBackup package? (Had to turn it often many times lately, the server seems totally overloaded/near collapse).

ljorgensen

@jahonix:

With or without traffic data?

With.

It could help potentially if you give a hint on your system, e.g. CPU, Ram and storage.
I expereience this on ALIX and APU1 systems but I expect it due to limited resources.

Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
8 CPUs: 1 package(s) x 4 core(s) x 2 SMT threads

Load average 0.91, 0.66, 0.56
CPU usage 4%
Memory usage 16% of 6099 MiB
SWAP usage 0% of 16383 MiB
Disk usage ( / ) 1% of 117GiB - ufs
Disk usage ( /var/run ) 4% of 3.4MiB - ufs in RAM

I'm not using the Backup-package. I scp config.xml out every night by a (remote) cron job.

Thing I observed today: If I change a firewall rule it says on the top to hit the Apply button to activate the change. If I hit it right away, the wait incurs. If I wat for about 20 seconds and hit it, the applying is instant. It seems something goes on in the background that blocks certain processes.

johnpoz

what other if any packages are you running? What browser are you running and with what addon's or extensions.

That box is a freaking supercomputer to what I run mine on, little vm running old hp 40L microserver also running other vms.. pfsense only has 1 gig given to it and 2 cpu and see no such delay..

ljorgensen

@johnpoz:

what other if any packages are you running? What browser are you running and with what addon's or extensions.

I have the OpenVPN Configuration Generator (or whatever it is called) installed as the only thing. I'm usually running in Safari (on a Mac), but just tried it in Chrome, and the behaviour is the same. Chrome has no plugins installed. Safari has Ghostery.

Looking in the system.log I see this when I make changes:


Feb 13 09:24:46 pfsense-01 check_reload_status: Syncing firewall
Feb 13 09:24:48 pfsense-01 php-fpm: /rc.filter_synchronize: Beginning XMLRPC sync to https://192.168.17.2:443.
Feb 13 09:25:02 pfsense-01 php-fpm: /rc.filter_synchronize: XMLRPC sync successfully completed with https://192.168.17.2:443.
Feb 13 09:25:05 pfsense-01 php-fpm: /rc.filter_synchronize: Filter sync successfully completed with https://192.168.17.2:443.

That time span corresponds pretty good with the delay in the UI. Could that be the problem and is there a way to speed it up?

Lars

johnpoz

So you have a carp setup? I don't run carp so not sure why it would slow anything down. Where is 192.168.17.2 not sure why it would take like 20 seconds to sync

ljorgensen

@johnpoz:

So you have a carp setup? I don't run carp so not sure why it would slow anything down. Where is 192.168.17.2 not sure why it would take like 20 seconds to sync

Yes, it's CARP. 192.168.17.2 is the other end of the dedicated SYNC interface.

johnpoz

You might have wanted to mention CARP in your first post ;) I have like zero experience with CARP on pfsense so not going to be much help. I could try and simulate in my setup.. But sending what I would assume is a tiny amount of data across a sync connection should not take 20 seconds.

Maybe there is an issue with the other box in your carp? maybe there is duplex mismatch or something in your interfaces?

ljorgensen

@ljorgensen:

I may be completely out on a limb here, but could it have anything to do with RRD data being stored in config.xml? Are they compressed and encoded every time I make a configuration change? config.xml is about 6 MB.

That <rrddata>element in the config.xml still bothers me. I disabled RRD graphs on the box, deleted all <rrddata>elements in the config. The file size went from 6+ MB to 400K. Then I tried to make a change to the config. It was noticeably faster. Then I tried one more change, and it was as sluggish as ever.

I looked at the config.xml, and it was right back to 6MB and full of rrddata elements. Is there somewhere else I need to configure for this to go away?

I'm on 2.3.4 in a HA setup on powerful hardware.

Lars</rrddata></rrddata>

ljorgensen

@ljorgensen:

deleted all <rrddata>elements in the config.</rrddata>

This time I did it with viconfig and they stayed gone. Things are much faster now.

How did they end up there in the first place? I have reinstalled it on newer hardware a couple of times from a backup with rrddata in the config. I thought it was supposed to remove that data after restore.