Using FastCGI

About FastCGI

FastCGI is used by default since version 10. Previously used ISAPI caused serious issues. (PHP has many issues and is very unstable when run with ISAPI modules in heavy load.) FastCGI takes care of these issues by communicating to multiple instances of PHP executables. IceWarp Server starts several instances of php.exe and forwards the PHP requests to it using TCP sockets. Should a problem with PHP occur, php.exe is simply killed and new instance is created without affecting the Web Server at all and the load is effectively balanced between the running instances of php.exe. Remember that the FastCGI mode can be a little bit slower than the default ISAPI one hence you may use it only after you are sure there is no other possible solution.

FastCGI Configuration

Use the dropdown selection in Administration GUI - Web Service settings which allows you to switch between Web Server modes with pre-defined settings. For more options, to fine tune the settings to your particular installation, or to make any changes manually, you will need to edit the [Installation Directory]\config\webserver.dat configuration file, as instructed further.

FastCGI Configuration

If you want to enable FastCGI for specific extension, simply modify the webserver.dat file (can be found in <install_dir>\config) by replacing all php\php.dll with (fastcgi);php\php.exe.

Original form: (ISAPI)

Now check the settings in the Web Service - Web Site - Scripting tab just to be sure, it should be set like this after the previous changes in webserver.dat:

Figure. Scripting settings.

FastCGI Advanced Options

Behaviour of PHP through FastCGI can be modified using following webserver.dat options.

where:

Parameter	Description
<FCGI_INITSERVERS>	number of instances of php.exe which are running immediately after start.
<FCGI_MAXSERVERS>	maximal number of running instances.
<FCGI_BINDIP>	IP address bound to php.exe and used to communication between IceWarp Server and PHP. This value has to be set. Usually there is no need to put other value than 127.0.0.1 here.
<FCGI_ENVIRONMENT>	environment variables, which are sent to php.exe to control its behaviour.
PHP_FCGI_MAX_REQUESTS	this environment variable tells php.exe to quit automatically after given number of processed requests.
<FCGI_MAXROUNDS>	similar option as PHP_FCGI_MAX_REQUESTS, but the counting of requests and killing of instances is responsibility of IceWarp Server and not php.exe itself.
<FCGI_CHECKRUNNING>	boolean value - if set to true, each instance of php.exe is checked, whether it is running or not, before trying to send data to it. This brings slowdown and it is not needed when PHP_FCGI_MAX_REQUESTS is greater than FCGI_MAXROUNDS.

FastCGI Timeout Modifier

This modifier allows to override FastCGI timeout. Global timeout still remains as set. The current solution for named modules (i. e. those with names in brackets, e. g. [activesync]) is as follows:

The following syntax can be used for unnamed modules, supported only with FastCGI(.exe):

<MODULE>(fastcgi)var/phpsocket;scripts/phpd.sh;TIMEOUT</MODULE>

where TIMEOUT is a value in milliseconds, the default setting is 1800000. (This example is from the Linux version.)

If you wish to set the ActiveSync heartbeat higher than the default maximum of 30 minutes, you need to modify the module's settings to extend PHP session time-out. Setting it lower should not be required and this modifier can be omitted (including the semicolon).

FastCGI timeout is accessible via $_SERVER ($_SERVER["FCGI_TIMEOUT"])

FastCGI timeout value defined in webserver.dat file can be easily obtained inside PHP script from $SERVER array.
It will help to determine you how often icewarp_keepalive( $tid ) should be called to survive.

FastCGI Quick How-to

Thread Pooling - open the webserver.dat file and set thread pooling to 10 (see higher). Restart the services and you will now see separate instances of php.exe running in the task manager.

Usually, 10 threads is a good starting point. It means 10 php.exe files are opened and used when there is processing. For example, you might have 100 users logged to IceWarp WebClient, but actual requests are much lower.

In the Control logs, you will see:

In this case, for Web service, we set 10 threads. So up to 10 open php.exe files. You can see in Global that none are being currently used. If, for example, it shows Inside=10, you might have problems to access WebClient. You have to increase number of threads. Or better, find the reason why they are used. It can be because of many users, but it can be also because of some problem. Also user should consider, that each php xonsumes system resources. Setting this value too high is nonsense and will kill the server.

Problems could also occur when messages to large mailing lists or groups are sent. The solution is to set Maximum number of messages to sent out in one minute in mailing lists and group accounts (the [group/mailing_list] - Options tab) to some reasonable value (say 40).

Example

of thread pooling in the webserver.dat file (not related to values shown above):

MySQL PDO

You should also move the WebClient PDO storage to a database. The instructions for doing it are below.

https://esupport.icewarp.com/index.php?/Knowledgebase/Article/View/370/40/we-do-not-relay-errors-when-sending