How to improve the speed of the pfSense GUI

[cybrsrfr]

A week or so ago I set out to find a way to make the GUI run faster on PFSense. I knew pfSense uses http://www.lighttpd.net/ for the web server. I've heard that this is supposed to be a very fast web server so I started researching why pretty slow on PFSense no matter what the speed of the computer is that is running pfSense. The performance with the webgui becomes very apparent if you are using captive portal. On one of my installs captive portal is seeing enough users around a 100 which after a reboot they all try and connect to pfSense's GUI through captive portal at the same time. This made captive portal and the pfSense GUI become totally unresponsive.

So I started looking at pfSense's web server config to see if it could run faster. I found that the default web server config for pfSense has been designed to minimize resources (ram and cpu) that lighttpd uses on the firewall for a machine with limited resources. However my installation is on a full install on so resources are available and lighttpd can be given more resources allowing for it to perform better in user concurancy. The changes I'm about to share are only recommended if your system needs a more scalable pfSense GUI. However you can experiment and adjust it to get the pfSense GUI responsiveness that you desire.

Warning: before doing the following, you should know if you do it wrong the web server may fail to start and pfSense gui will not work.

Lighttpd config for pfSense is in: (warning: changes directly to these files are only temporary)
/var/etc
lighty-CaptivePortal.conf
lighty-webConfigurator.conf

To make changes permanent edit the following file. Note: If you do an upgrade to pfSense your files will need to be re-added.

You can edit the file either with by enabling ssh and then using ssh to login and edit the file with vi. Or you can use an sftp client to download and update the files. And the third option is change through Diagnostics->Edit File.

Warning: These changes are meant for a full install and increased my ram usage.
In my case using captive portal I needed these changes your needs may be different.
PHP_FCGI_CHILDREN = "16"
max_requests = 250

If you are not using captive portal with several users behind it then you can still use use these
changes but I recommend a much lower numbers. Something like the following or possibly even lower.
PHP_FCGI_CHILDREN = "16"
max_requests = 16

Edit the following file.
/etc/inc/system.inc

Look for the system_generate_lighty_config php function:

–-----------------------------------------------------------
Before Changes on PFSense 1.2

fastcgi module

read fastcgi.txt for more info

fastcgi.server = ( ".php" =>
( "localhost" =>
(
"socket" => "/tmp/php-fastcgi.socket",
"min-procs" => 1,
"max-procs" => {$max_procs},
"bin-path" => "/usr/local/bin/php"
)
)
)

---

After Changes

fastcgi module

read fastcgi.txt for more info

fastcgi.server = ( ".php" =>
( "localhost" =>
(
"socket" => "/tmp/php-fastcgi.socket",
"min-procs" => 1,
"max-procs" => {$max_procs},
"bin-environment" => (
"PHP_FCGI_CHILDREN" => "16",
"PHP_FCGI_MAX_REQUESTS" => "{$max_requests}"
),

"bin-path" => "/usr/local/bin/php"
)
)
)

The change that I added is the following:

"bin-environment" => (
"PHP_FCGI_CHILDREN" => "16",
"PHP_FCGI_MAX_REQUESTS" => "{$max_requests}"
),

---

Additional Notes:

You might also try increasing the max_requests as I have done for my system:
max_requests = 250;

For more information use the following link and look for keyword: PHP_FCGI_CHILDREN.
http://trac.lighttpd.net/trac/wiki/FrequentlyAskedQuestions

Some experimentation and you can find the ideal PHP_FCGI_CHILDREN and max_requests that achieves the right balance of your resources and need for speed.

[cmb]

Yeah the default settings aren't good if you have a large CP deployment where 100+ users will be logging in at the same instant, since that requires PHP for each user.

I opened up a feature request ticket on this to include tunable settings in the GUI to increase these limits, we'll get that added to 1.3.

[cybrsrfr]

Tunable settings from the GUI would be perfect for pfSense 1.3.

[sullrich]

Why not just base these values on the amount of ram installed?   Why let someone shoot themselves in the foot when we can calculate these numbers by the amount of ram installed?

I just commited a few changes to auto size these numbers.  Need to revise the formula a bit but it is a good start.

[cybrsrfr]

Great Job! Your idea of basing it off ram is a good idea and keeps things simple for the user. PFSense just keeps getting better and better.

Some thoughts that were inspired by the following link:
http://trac.lighttpd.net/trac/wiki/FrequentlyAskedQuestions#HowmanyphpCGIprocesseswilllighttpdspawn

The link above shows the following:

PHP_FCGI_CHILDREN (defaults to 1)

max-procs (default 4)

min-procs is completely ignored in recent lighttpd releases (there is no adaptive spawning anymore)

Since min-procs is ignored line 836 is unnecessary. (http://cvstrac.pfsense.org/chngview?cn=22302)
"min-procs"  =>  1,

From the testing I did I noticed additional procs require more ram than PHP_FCGI_CHILDREN. From what I have seen max-procs defines the number of seperate processes and PHP_FCGI_CHILDREN defines the allowed PHP files that are allowed to be processed in a each process.

I have read a large number of posts on the forum (not as many as sullrich or many others) there are a number of users that are not using captive portal that are reporting that the PFSense GUI is slow. I've also experienced this first hand. I recommend increasing the PHP_FCGI_CHILDREN a little on the default install which could improve the speed while limiting resources used. Since the default is 1 for PHP_FCGI_CHILDREN setting it to 2 or 3 could make a big difference and make pfSense GUI much faster.

One last note is:
PHP_FCGI_MAX_REQUESTS seems to be how many PHP requests get processed before the lighttpd shuts the process down and builds a new one. This implies greater stability over a length of time when the process is eventually renewed.

Best Regards!

[sullrich]

I agree 100%.  Do you want to roll a patch for these as well? :)

[drees]

Yep, setting max-requests so low is counter productive. PHP_FCGI_CHILDREN is too big for small boxes.

Are there any calls to system_generate_lighty_config which explicity disable fast_cgi?

I would suggest this:

98MB or less - explicity disable FastCGI - it's already effectively disabled by the settings anyway.

Keep max-procs at 1. Since we use the APC cache, it's more effective to increase PHP_FCGI_CHILDREN since then they can share memory used by the APC cache.

Increase max-requests significantly. This will reduce the overhead of killing/forking new PHP processes.

In the existing code, there is currently a bug in the config generation for boxes with more than 512MB of memory. They get stuck with the default settings. If we want to be able to make the $max_procs, $max_children and $max_requests overridable/configurable, we should probably change the default values in the function definition to null values so we know when they've been set.

I've attached a patch (against 1.79.2.116) and new system.inc to show the changes I've suggested (not tested yet, any guinea pigs?)

system.inc.txt
system.inc.patch.txt

[drees]

I tested the changes. I didn't see any real performance difference in my testing. Response times remained within a small margin of error with the old settings and with the new on a 256MB ALIX firewall and a 1GB PIV 2.8GHz desktop firewall.

However, the new settings did reduce the amount of memory used by php. Not that big a deal on the big memory machines, but a significant improvement on lower end machines.

So I've tweaked the settings a bit more. Changes from the last version:

1. Don't disable fast_cgi on tiny boxes. I misunderstood the previous settings and having fast_cgi enabled really makes a big difference even on a tiny box.
2. More aggressive settings for max_children and max_requests for "larger" boxes.

system.inc.txt