PHP Performance on Windows – slides

There were a number of question at the end of the webcast that we did not get to answer due to lack of time. This blog post provides answers to those questions.

Q: Why is php_mssql.dll removed from php 5.3.2?
A: The reason why it was removed was because of an incompatible driver. The last SDK supported by Microsoft was not compatible anymore with VC6. Anyway, php_mssql.dll is not recommended to be used with SQL Server because there is a SQL Driver for PHP that is officially supported by Microsoft. You can get more information about the driver at Working with Microsoft SQL Server driver (php_sqlsrv.dll) for PHP on Windows.

Q: How can we have .htaccess file features work on IIS? Is there an alternative?
A: There are several options. If you just want Apache mod_rewrite rules to work on IIS, then you can import them from a .htaccess file. If you want complete support for all .htaccess features then you can try Helicon Ape from HeliconTech. Regarding PHP specific features in .htaccess file – for PHP 5.2 you could use htscanner PECL extension. In PHP 5.3 there is a new feature for per directory PHP configuration and .user.ini files.

Q: Do you have any numbers to compare iis performance with other web servers(apache, nginx, lighttpd)?
A: No, we do not have any numbers that can be shared. It’s difficult to come up with an objective test that compares web server technologies – there are too many variables and interpretations of the results and even if Microsoft ever produced such numbers they would probably cause a lot of controversy over the objectivity of those tests.

Q: Do you plan to implement wincache library for Zend Framework(Zend_Cache)?
A: WinCache team does not have plans for that, but there is already a PHP developer who is working on implementing this: http://github.com/juokaz/wincache.

Q: We have discussed here sugar CRM. Is Microsoft planning to do enhancement in sugar CRM functionality?
A: Microsoft works well with Sugar CRM development team and Sugar CRM add enhancements to their future versions to support new features from Microsoft, such as WinCache user and session cache for example. Microsoft, however does not contribute any code and does not work directly on any enhancements to Sugar CRM.

Q: Is Microsoft planning to develop any dll which can make PHP code to Intermediate language?
A: Assuming that the question is about .NET intermediate language – no, there are no plans for this.

Q: Would there be any tool in Microsoft development tool kit for PHP?
A: There are several projects in Microsoft that provide development tools and instructions for enabling interoperability between PHP and other Microsoft technologies. You can find more details about those projects here: http://www.interoperabilitybridges.com/.

Q: Is WinCache shared data accessible for CLI? Script A launches Script B, C and D … ?
A: Yes, you can access the shared data from CLI as long as you set wincache.enablecli = 1 in php.ini and all the CLI processes have the same parent process.

Q: Are the statistics results of WinCache the same in 5.2.13 as in 5.3?
A: If the question is about wincache.php statistics script then yes – the data presented by that script is the same regardless of the PHP version.

Q: Are there any security concerns with having wincache store session data in shared memory?
A: If you use different IIS application pools for different web sites (which is the recommended configuration), then WinCache ensures that those web sites can not access each other’s cache data. All caches, not just the session cache are not shared across IIS application pools.

Q: Is it safe to write to the user cache assuming data disappears from the system after the cache times out? Is the content of the user cache in wincache 1.1 written to disk at all?
A: Normally the data in the user cache is deleted from the cache after the time to live interval, but the deletion happens on the main request processing thread. This means that if there are no requests to process, the entries in the cache may stay longer than the TTL. WinCache does not write user cache content to disk, but if memory pagefile is enabled on the server, then it may happen that the memory content will be stored by OS in a pagefile. If a maching (not just a process) crashes when user cache content is in the pagefile, then the content may be present on disk.

Q: Is the sqlsrv driver going to be compatible with PDO?
A: SQL Driver for PHP 2.0 will include PDO support.

Q: Is there any documentation on securely configuring php/FastCGI in a shared application pool environment on IIS6 so that websites?
A: Check the article about setting up PHP on IIS6 and look for the section called “Impersonation and file system access”. If this is not what you are looking for – let me know.

Q: When are we going to see PHP 5.3 in the WPI?
A: Web PI team is planning to add support for PHP 5.3 in near future. Most probably it will be possible to select which version of PHP to install from Web PI. This is because there are some PHP applications in Web PI that will never support PHP 5.3.

Thanks to all who has attended the webcast and asked interesting questions!

The latest releases of the FastCGI Extensoin 1.5 and FastCGI update for IIS 7.0 have a new configuration setting monitorChangesTo that takes an absolute path to a file that FastCGI will monitor for changes. In case of PHP this means that you can set monitorChangesTo to a path to php.ini file, so that any time it is modified the FastCGI module will restart the php-cgi.exe to pick up the configuration changes.

Assuming that the PHP configuration file location is C:\PHP\php.ini, the instructions below describe how to use monitorChangesTo on different IIS versions:

• IIS 5.1 and IIS 6.0
• IIS 7.0
• IIS 7.5

IIS 5.1 and IIS 6.0

The FasCGI configuration is stored in a file %windir%\system32\inetsrv\fcgiext.ini. You can manually update it to use monitorChangesTo:

[Types]
php=PHP

[PHP]
ExePath=C:\PHP\php-cgi.exe
MonitorChangesTo=C:\PHP\php.ini

Alternatively you can use the configuration helper script %windir%\system32\inetsrv\fcgiconfig.js :

cscript %windir%\system32\inetsrv\fcgiconfig.js -set -section:PHP -MonitorChangesTo:C:\PHP\php.ini

IIS 7.0

You will need to install the FastCGI Update in order to be able to use monitorChangesTo in IIS 7.0 on Windows Vista and Windows Server 2008.

To configure this setting, use the command below:

%windir%appcmd.exe set config -section:system.webServer/fastCgi ^
/[fullPath='C:\PHP\php-cgi.exe',arguments=''].monitorChangesTo:"C:\PHP\php.ini" ^
/commit:apphost

IIS 7.5

In Windows 7 and Windows Server 2008 R2 you can use the same appcmd command as described above or you can use IIS Manager user interface for FastCGI settings:

Technical Notes

Below are the technical details that you need to be aware of when using this new feature in FastCGI module:

• The file that monitorChangesTo is pointing to must exist on a file system. If it does not exist then FastCGI module will generate an error;
• If the file is located on a network share then FastCGI module cannot use Windows file change notifications so it will switch to polling and will check the file for changes every 5 seconds;
• If a relative file path is specified instead of an absolute path then FastCGI will assume that it is relative to the location of php-cgi.exe file.

The update can be downloaded from the following locations:

• Update for Windows Server 2008 (KB980363)
• Update for Windows Server 2008 for Itanium-based Systems (KB980363)
• Update for Windows Server 2008 x64 Edition (KB980363)
• Update for Windows Vista (KB980363)
• Update for Windows Vista for x64-based Systems (KB980363)

The features that are enabled by this update:

• Monitor changes to a file. The module can be configured to listen for file change notifications on a specific file and when that file changes, the module will recycle FastCGI processes for the process pool. This feature can be used to recycle PHP processes when changes to php.ini file occur. To enable this feature use the monitorChangesTo setting in the <fastCgi> configuration element.
• Real-time tuning of MaxInstances setting. This MaxInstances setting dictates the maximum number of FastCGI processes which can be launched for each application pool. Set it to 0 to let FastCGI module automatically adjust the number of instances up or down based on the system load and number of requests waiting in the queue.
• STDERR stream handling. There are several options of how the module can handle text sent by FastCGI application on STDERR. The module can send the error data as a failure response to the HTTP client or it can ignore the error and send whatever was received on STDOUT as a response with 200 status code. This behavior is controlled by the stderrMode setting.
• Sending a termination signal to FastCGI processes. The module can be configured to send a termination signal to FastCGI process before terminating it. This enables FastCGI processes to do a clean shutdown before getting killed. The signalBeforeTerminateSeconds setting can be used to specify how long the module will wait before it forcefully shuts down the FastCGI process that does not respond to the termination signal. This feature is disabled by default.
• _FCGI_X_PIPE_ environment variable. This variable is set by FastCGI module and it contains the name of the named pipe that is used for communication between the module and FastCGI process.
• Relaxed enforcement of response headers syntax. The FastCGI module now has less strict enforcements for the correctness of the response headers.
• Using UTF-8 encoding for server variable values. By default FastCGI uses ASCII encoding when setting server variables. If a FastCGI application requires UTF-8 encoded values for certain server variables, the module can be configured to use UTF-8 only for required server variables. Follow these instructions to enable this functionality.

In addition to that several important bugs have been fixed, most notable of those are the ones reported by Franklin Tse:

• FastCGI module replaces redirect status code set by PHP with HTTP 302
• Custom application errors were masked by the generic IIS errors

If you are using IIS 7.0 to host PHP applications, then it is highly recommended to apply this update to ensure you have the latest version of FastCGI module.

The information in this post is not applicable anymore because the update for FastCGI module in IIS 7.0 has been made available, so now the functionality and features of FastCGI are consistent across all IIS versions. Read the release announcement to get more details about the update.

Recent release of FastCGI Extension 1.5 for IIS 6.0 and IIS 5.1 has several new features and improvements that make it easier to run PHP on Windows and IIS. However, all the new features are only available when using Windows XP or Windows Server 2003. FastCGI module on IIS 7.5 in Windows 7 and Windows Server 2008 R2 supports most of these features. FastCGI module on IIS 7 in Windows Vista and Windows Server 2008 does not support those new features yet. The reasons why this happens and the plan for updating FastCGI functionality across all platforms are explained in this post.

FastCGI is supported across 4 different versions of IIS: IIS 5.1/6.0, IIS 7.0 and IIS 7.5. The release models for each of those versions are different:

• FastCGI Extension for IIS 5.1 and IIS 6.0: This is a separate add-on, which is shipped independently of IIS and Windows OS. IIS team has a lot of control over the release schedule and is able to release updates and fix bugs in the extension relatively fast. Thus the new FastCGI features were first introduces in this extension.
• FastCGI Module for IIS 7.0: The module is included in IIS and is therefore a part of the already shipped operating system. Updating the OS component, while possible, requires more time as the changes have to go through the standard Windows Servicing process. The update to the IIS 7.0 FastCGI Module that includes all the new FastCGI features is currently in the release stage and will soon be publicly available for download. The update for the IIS 7.0 FastCGI Module has been released.
• FastCGI Module for IIS 7.5: FastCGI module is included in IIS and is a part of the operating system. However, the development phase for IIS 7.5 coincided with the release of the FastCGI Extension 1.5 thus the majority (but not all) of the new FastCGI features are available in IIS 7.5. The remaining updates to the FastCGI Module for IIS 7.5 will be done in Windows Server 2008 R2 Service Pack.

The following table lists the new FastCGI features and their availability in different versions of IIS:

* – Install the FastCGI update for IIS 7.0 to get all the features listed above.

Install FastCGI Extension 1.5 for IIS 6.0 and IIS 5.1

To install the FastCGI Extension 1.5 use the download links at the extension’s home page at http://www.iis.net/expand/fastcgi.

Note: If you already have FastCGI v1.0, v1.5 Beta or v1.5 RC installed, then the installation package will upgrade it to version 1.5 – RTW. All the related IIS configuration and settings in fcgiext.ini file will be preserved during upgrade. Note that during upgrade from v1.0 the comments in fcgiext.ini will not be updated and will not mention new configuration settings. However the new settings can still be used after upgrade.

New Features

The FastCGI Extension 1.5 includes these new features:

• Monitor changes to a file. The extension can be configured to listen for file change notifications on a specific file and when that file changes, the extension will recycle FastCGI processes for the process pool. This feature can be used to recycle PHP processes when changes to php.ini file occur.
• Real-time tuning of MaxInstances setting. This MaxInstances setting dictates the maximum number of FastCGI processes which can be launched for each application pool. If it is set to 0 then FastCGI extension will automatically adjust the number of instances up or down every few seconds based on the system load and number of requests waiting in the queue. 
• STDERR stream handling. There are several options of how the extension can handle text sent by FastCGI application on STDERR. The extension can send the error data as a failure response to the HTTP client or it can ignore the error and send whatever was received on STDOUT as a response with 200 status code.
• Sending a termination signal to FastCGI processes. The extension can be configured to send a termination signal to FastCGI process before terminating it. This enables FastCGI processes to do a clean shutdown before getting killed.
• _FCGI_X_PIPE_ environment variable. This variable is set by FastCGI extension and it contains the name of the named pipe that is used for communication between the extension and FastCGI process.
• Relaxed enforcement of response headers syntax. The FastCGI extension has less strict enforcements for the correctness of the response headers.
• Per-application FastCGI process pools. In previous version of the extension, the FastCGI process pools could be defined for the entire IIS server or per IIS site. In FastCGI 1.5 it is also possible to define FastCGI process pool per IIS application, which allows to have two different PHP version used for different applications within the same web site.
• Using UTF-8 encoding for server variable values. By default FastCGI uses ASCII encoding when setting server variables. If a FastCGI application requires UTF-8 encoded values for certain server variables, the extension can be configured to use UTF-8 only for required server variables.
• More descriptive error messages are used when configuration in fcgiext.ini is incorrect
• Changes in default values for configuration settings. MaxInstances is now set to 0, so that real-time tuning of MaxInstances is enabled by default. ActivityTimeout is set to 70 seconds.

More information

Refer to the following resources for more information

• FastCGI Extension 1.5 configuration settings
• Using FastCGI Extension to run PHP applications on IIS5.1 and 6.0
• PHP community portal on IIS.NET

Also, be sure to visit the FastCGI Handler forum on IIS.NET if you have run into any problems when using the extension or have questions or suggestions.

In order to setup multiple versions of PHP side by side on the same IIS server it is necessary to install PHP manually by following the steps described in php.net documentation for IIS 5.1 and IIS 6.0 and for IIS 7.0 and later. Do not use PHP Windows installer because it does not support side by side installations.

After a particular version of PHP has been installed in accordance to the instructions, download another version of PHP, extract it into a separate directory and configure it in accordance to Manual Installation Steps. After that proceed to configuring an IIS server as per instructions below:

• IIS 5.1
• IIS 6.0
• IIS 7.0 and later

Note: in all examples below two PHP versions are installed on the same server. PHP 5.2.11 files are located in C:\PHP5211\ directory and PHP 5.3.1 files are located in C:\PHP531\ directory.

IIS 5.1

The FastCGI Extension can be configured on a server and a site level. Since IIS 5.1 can have only one web site, it is not possible to configure it to have two versions of PHP running at the same time. But it is possible to have a configuration that allows to easily switch from one version to another.

Open the IIS FastCGI extension configuration file at %windir%\system32\inetsrv\fcgiext.ini. At the end of the file there will be a section that defines FastCGI applications. It may look similar to this:

[Types]
php=php5211

[php5211]
ExePath=C:\php5211\php-cgi.exe

This configures IIS to use PHP 5.2.11 whenever a request for a *.php file is made. To switch to PHP 5.3.1, just add another section declaration and then modify the [Types] section as below:

[Types]
;php=php5211
php=php531

[php5211]
ExePath=C:\php5211\php-cgi.exe

[php531]
ExePath=C:\php531\php-cgi.exe

To switch back to PHP 5.2.11 update the [Types] section by commenting out php=php531 and un-commenting php=php5211. There is no need to restart IIS after the updates to fcgiexe.ini have been made. FastCGI Extension will pick up the changes as soon as file has been saved.

IIS 6.0

FastCGI on IIS 6.0 can be configured on a server level, which would cause all the IIS web sites to use the same PHP version. Configuring FastCGI on a server level and switching between PHP versions is exactly the same procedure as for IIS 5.1.

Additionally FastCGI can be configured on a site level, which would allow using of different PHP versions for different web sites. To assign a particular PHP version to a site, use the following commands. Make sure to replace the <site_id> with real site identifiers.

cscript %windir%\system32\inetsrv\fcgiconfig.js -add -section:"php5211" ^
-extension:php -path:"C:\php5211\php-cgi.exe" -site:<site_id>

cscript %windir%\system32\inetsrv\fcgiconfig.js -add -section:"php531" ^
-extension:php -path:"C:\php531\php-cgi.exe" -site:<site_id>

After executing these commands open the fcgiext.ini file located in %WINDIR%\system32\inetsrv. It should contain the following sections:

[Types]
php:169297538=php5211 ; The actual site id will be different for your site
php:273357939=php531 ; The actual site id will be different for your site

[php5211]
ExePath=C:\php5211\php-cgi.exe

[php531]
ExePath=C:\php531\php-cgi.exe

IIS 7.0 and later

FastCGI module in IIS 7.0 can be configured on any level: server, site, application and folder. This means that it is even possible to have two applications using different PHP versions within the same web site.

To configure FastCGI on a server level, use these commands:

%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI ^
/+[fullPath='c:\php531\php-cgi.exe']

%windir%\system32\inetsrv\appcmd set config /section:system.webServer/handlers ^
/+[name='php531', path='*.php',verb='*',modules='FastCgiModule',^
scriptProcessor='c:\php531\php-cgi.exe',resourceType='Either']

Repeat these commands for all the other versions of PHP. By default IIS will use the version that was added last. Now, if you need to use a particular version of PHP for the entire server or for a particular web site, you can just re-order the FastCGI handler mappings for PHP.

Open IIS Manager and use a tree view on left hand side to select a server, site or an application. After that click on “Handler Mappings”:

Then click on “View Ordered List…” action:

Select the handler mapping for the PHP version that you want to use for the server or a site and use “Move Up” action to move it to the top of the list. This will enable that particular PHP version for the currently selected IIS configuration scope.

Note that if you re-order handler mappings on a site or an application level, that site or application will stop inheriting the handler mappings from the upper configuration levels, so the changes to the handler mappings on the server level will not propagate to the site level anymore. To configure a site or an application back to using the inherited handler mappings, use the “Revert To Parent…” action:

However there was one thing in the PHP docs that was still not up-to-date. The Windows and IIS-specific installation and configuration sections did not cover the latest changes in Windows, such as IIS 7 and FastCGI. Now I am glad to let everyone know that this part of the PHP documentation is also being updated!

Check out the first batch of updates:

• Manual Installation Steps
• Microsoft IIS 5.1 and IIS 6.0
• Microsoft IIS 7.0 and later

The content is still being updated and there are plans to add more instructions, such as how to install PHP on Windows with PHP Installer, how to easily upgrade to PHP 5.3, how to run multiple PHP versions side by side, etc. If you have any suggestions on the updated content or if you have any additional instructions that you think will be useful, please submit user notes on PHP.NET.

The Windows Cache Extension for PHP can be used to improve performance of PHP applications running on Windows operating systems. The extension caches the compiled PHP opcode in the shared memory, which helps to avoid re-doing of such CPU intensive operations as parsing and compiling of the PHP source code. This means that when Windows Cache Extension for PHP is enabled, less CPU cycles are required for a web server to process PHP requests. Because of that, the previously configured value for the FastCGI maxInstances setting may not be adequate to load the server’s CPU completely and it may be necessary to increase the value further.

To increase the maxInstances value on IIS 7 run this command from an elevated command line prompt:

appcmd.exe set config  -section:system.webServer/fastCgi /[fullPath='C:\PHP\php-cgi.exe',arguments=''].maxInstances:"32"  /commit:apphost

Note: replace the fullPath with the path to php-cgi.exe on your server.

Alternatively you can just edit the <fastCGI> section the applicationHost.config file located at C:\Windows\System32\inetsrv\config\ folder:

<fastCgi>
  <application fullPath="C:\PHP\php-cgi.exe" maxInstances="32">
  <!-- Some other settings may go here-->
  </application>
</fastCgi>

To increate the maxInstances value on IIS 5.1 and IIS 6.0 run this command:

>cscript C:\windows\system32\inetsrv\fcgiconfig.js -set -section:"PHP" –MaxInstances:32

Note: replace the section name if necessary.

Alternatively you can edit the fcgiext.ini file located at C:\Windows\System32\inetsrv\ folder:

[PHP]
ExePath=C:\PHP\php-cgi.exe
;some other settings may go here
MaxInstances=32

When you measure the performance of the Windows Cache Extension for PHP, make sure to monitor the CPU usage. If you see that CPU is not fully utilized try increasing the FastCGI maxInstances setting and you may be able to get better performance results.

Install the Windows Cache Extension 1.0 for PHP – Beta

or, download:

Windows Cache Extension 1.0 for PHP 5.2 – Beta

Windows Cache Extension 1.0 for PHP 5.3 – Beta

Follow the instructions at “Using Windows Cache Extension for PHP” to install, enable and configure the extension.

Note:

• The extension can only be used with non-thread-safe builds of PHP
• The extension can only be used when IIS is configured to run PHP via FastCGI
• The Windows Cache Extension 1.0 for PHP 5.3 can only be used with the x86 VC9 build of PHP 5.3.

Benefits and Features

The extension includes three caches that can be enabled or disabled independently of each other:

• PHP opcode cache – PHP is a script processing engine, which reads an input stream of data that contains text and/or PHP instructions and produces another stream of data, most commonly in the HTML format. This means that on a web server the PHP engine reads, parses, compiles and executes a PHP script each time that it is requested by a Web client. The reading, parsing and compilation operations put additional load on the web server’s CPU and file system and thus affect the overall performance of a PHP web application. The PHP bytecode (opcode) cache is used to store the compiled script bytecode in shared memory so that it can be re-used by PHP engine for subsequent executions of the same script.
• File cache – Even with the PHP bytecode cache enabled, the PHP engine has to access the script files on a file system. When PHP scripts are stored on a remote UNC file share, the file operations introduce a significant performance overhead. The Windows Cache Extension for PHP includes a file cache that is used to store the content of the PHP script files in shared memory, which reduces the amount of file system operations performed by PHP engine.
• Relative file path cache – PHP scripts very often include or operate with files by using relative file paths. Every relative file path has to be converted to an absolute file path by the PHP engine. When a PHP application uses many PHP files and accesses them by relative paths, the operation of resolving relative paths to absolute paths may negatively impact the application’s performance. The Windows Cache Extension for PHP provides a relative file path cache, which is used to store the mappings between relative and absolute file paths, thereby reducing the number of relative path resolutions that the PHP engine has to perform.

More information

• Windows Cache Extension for PHP on IIS.NET
• Using Windows Cache Extension for PHP

Use the Windows Cache Extension for PHP Forum to ask questions, report bugs and provide feature suggestions.

Assume that you have two web sites in IIS – website1.com and website2.com. The root directory for website1.com is at C:\Inetpub\website1.com\ and the root directory for website2.com is C:\Inetpub\website2.com\ . Let’s say that the PHP application at website1.com does some heavy database activity and hence requires longer script execution time, which in PHP is controlled by max_execution_time setting. Also, let’s say that the PHP application at website2.com is a photo album, where visitors may upload very large image files. Because of that it requires bigger maximum allowed file upload size, which is controlled by the php.ini setting upload_max_filesize.

To enable the above described scenario on IIS, first you need to install PHP 5.3 and configure IIS to work with it. The easiest way is to use PHP Installer available at the community PHP site. Make sure to use the installer for VC9 non-thread-safe build of PHP 5.3 and choose the “IIS FastCGI” option during the installation. Alternatively, you can follow the instructions described in Using FastCGI to Host PHP Applications on IIS 7.0 and create the FastCGI handler/script mapping on the server level, so that it applies to all web sites on the server.

Now you have two options:

1. Define the per-site PHP settings in the main php.ini file
2. Allow web application owners to define those settings in user defined INI files.

For option #1 open the main php.ini file (if you used PHP installer, then this file will most probably be located at C:\Program Files\PHP\ folder. If you installed from a ZIP archive then the file will be at the same directory where php-cgi.exe file is). Add the following at the end of the file:

[PATH=C:/inetpub/website1.com/]
max_execution_time = 300

[PATH=C:/inetpub/website2.com/]
upload_max_filesize = 12M

Save the php.ini file and then recycle the application pools for these web sites for the php.ini changes to take effect.

After that you can use phpinfo() or ini_get(‘max_execution_time’) to check that these settings overwrite the default ones:

The output shows that the local value of max_execution_time setting (in the second column) is 300, while the master value, or default, is 30.

Alternatively, if you want to allow web application owners to control PHP settings themselves, you can enable user defined PHP configuration. To do that, add the following setting to main php.ini file:

user_ini.filename = .user.ini

This setting specifies the name to be used for user-specific ini files. Setting this to empty value disables the user defined PHP configuration.

After that create a file called .user.ini in C:\inetpub\website1.com\ folder and place and put this line into it:

max_execution_time = 300

Also, put this line into the file .user.ini in C:\inetpub\website2.com\ folder:

upload_max_filesize = 12M

Note that if your main php.ini file has [PATH] sections that point to the root folders of these sites, then you need to remove those sections; otherwise user defined settings will not take effect.

Again, you can use phpinfo() or ini_get() functions to check that the user defined settings overwrite the default ones:

One more thing that you need to be aware of when you enable the user defined ini files is that the settings in those files are cached by PHP engine to avoid re-reading those files for every request. This means that if the user makes a change to .user.ini file then that change may not take effect right away. Instead it may take effect after the cache time-to-live has expired. The cache TTL value is controlled by the php.ini setting user_ini.cache_ttl, which is set to 300 seconds (5 minutes) by default.