PHP used in production environments needs to be optimized to allow PHP itself to perform better. In addition to writing PHP code, php-fpm and php.ini tuning must also be configured. This article explains the configuration tuning of php.ini from the aspects of memory, OPcache, upload, session and security.
#Compared with other compiled languages, the biggest disadvantage of PHP is that each request will do some module parsing, and what is actually executed is the work process. Starting the work process requires more resources. At the same time, every request will re-parse some codes, resulting in repeated parsing.
For the optimization of PHP, you can focus on this aspect to consider optimization.
When running PHP, you need to care about how much memory each PHP process uses. The memory_limit setting in php.ini is used to set Determines the maximum amount of system memory that a single PHP process can use.
The default value of this setting is 128M, which may be suitable for most small and medium-sized PHP applications. However, if you are running a micro-PHP application, you can lower this value to save system resources. On the contrary, if If you are running a memory-intensive PHP application, you can increase this value. The size of this value is determined by the available system memory. Determining how much value to allocate to PHP is an art. When deciding how much memory to allocate to PHP and how many PHP-FPM processes it can afford, it can be judged based on the following dimensional information:
How much memory can be allocated to PHP? Take a VPS with 2G memory as an example. This device may also run other processes, such as MySQL, Nginx, etc., so it is appropriate to leave 512M for PHP.
How much memory does each PHP process consume on average? To monitor the memory usage of the process, you can use the command line command top, or you can call the memory_get_peak_usage() function in a PHP script. No matter which method is used, it must be used multiple times. Run the same script and take the average memory consumption.
How many PHP-FPM processes can you afford? Suppose I allocate 512M memory to PHP and each PHP process consumes an average of 15M memory, then I can afford 34 PHP-FPM processes.
Are there enough system resources? Finally, you need to confirm that there are enough system resources to run the PHP application and handle the expected traffic. For specific PHP configuration information, please refer to the php-fpm.config configuration file.
; Time limit for child processes to wait for a reaction on signals from master. ; Available units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 ;process_control_timeout = 0 ; The maximum number of processes FPM will fork. This has been designed to control ; the global number of processes when using dynamic PM within a lot of pools. ; Use it with caution. ; Note: A value of 0 indicates no limit ; Default Value: 0 ; process.max = 128 ; Specify the nice(2) priority to apply to the master process (only if set) ; The value can vary from -19 (highest priority) to 20 (lowest priority) ; Note: - It will only work if the FPM master process is launched as root ; - The pool process will inherit the master process priority ; unless specified otherwise ; Default Value: no set ; process.priority = -19 ; Send FPM to background. Set to 'no' to keep FPM in foreground for debugging. ; Default Value: yes daemonize = no
php-fpm has three operating modes, namely fixed number of processes, number of on-demand processes, and fully dynamic number of processes.
The number of processes on demand, a few processes are initialized by default. If the amount is too large, some new processes will be dynamically created. After the request is completed, the newly created processes will be destroyed. Lose.
Fix the number of processes. By default, a few processes are fixed. If the number of processes is not enough, new requests will be waiting and will not be processed until other processes have finished processing.
The number of completely dynamic processes means that it is completely controlled by the amount of requests. A process is created for each request and is destroyed after processing.
After determining how much memory to allocate, you can configure PHP’s Zend OPcache extension. OPcache mainly parses some codes into bytecode, so there is no need to repeatedly parse and compile this part of the code in subsequent requests. Reducing the compilation and parsing process can also improve PHP's processing speed.
PHP5.5.0 has this extension built-in. Here are some necessary configuration information:
opcache.memory_consumption = 64: The memory allocated for the opcode cache (unit is MB), the amount of allocated memory should be able to save the operation codes compiled by all PHP scripts in the application. This value can be set to different sizes according to the size of the application.
opcache.interned_strings_buffer = 16: The amount of memory used to store resident strings (unit is MB). What is a resident string? Behind the scenes, the PHP interpreter will find multiple instances of the same string and save the string in memory. If the same string is used again, the PHP interpreter will use a pointer. The purpose of this is to save memory. By default, PHP resident strings will be isolated in each PHP process. This setting allows the PHP-FPM process pool to store all process-resident strings in a shared buffer so that they can be processed in the PHP-FPM process pool. Resident strings are referenced between multiple processes, which saves more memory.
opcache.max_accelerated_files = 4000: The maximum number of PHP scripts that can be stored in the opcode cache. The range of this value is between 2000 and 100000. This value must be larger than that in PHP applications. The number of files is large.
opcache.validate_timestamps = 1: When the value of this setting is 1, PHP will check whether the content of the PHP script has changed after a period of time. The checking time interval is set by opcache.revalidate_freq specified. If the value of this setting is 0, PHP will not check whether the content of the PHP script has changed, and we must clear the cached opcodes ourselves. It is recommended to set it to 1 in the development environment and 0 in the production environment.
opcache.revalidate_freq = 0：设置多久（单位是秒）检查一次 PHP 脚本内容是否有变化。设置为0秒的含义是仅当opcache.validate_timestamps设置为1时，才会在每次请求时都重新验证 PHP 文件，因此，在开发环境中每次都会重新验证 PHP 文件，在生产环境中则不验证。
opcache.fast_shutdown = 1：这么设置能让操作码使用更快的停机步骤，把对象析构和内存释放交给 Zend Engine 的内存管理器完成。
如果你的应用允许上传文件，最好设置最大能上传的文件大小。除此之外，最好还要设置最多能同时上传多少个文件：
file_uploads = 1 upload_max_filesize = 10M max_file_uploads = 3
默认情况下，PHP 允许在单次请求中上传 20 个文件，上传的文件最大为 2MB，这里我设置为单次请求最多只能上传 3 个文件，每个文件最大为 10MB，这个值不要设置太大，否则会出现超时。
注：如果非要上传大文件，Web 服务器的配置也要做相应调整。除了在 php.ini 中设置之外，还要调整 Nginx 虚拟主机配置中的 client_max_body_size 设置。
此外，如果是上传特大文件，我建议使用Webuploader专门的上传组件，前端对大文件进行切片，后端php对分片数据进行合并还原文件。有关WebUploader应用请参考本站文章：功能强大的文件上传组件-WebUploader。
max_execution_time 用于设置单个 PHP 进程在终止之前最长可运行时间。这个设置默认是 30 秒，建议将其设置为 5 秒：
max_execution_time = 5
在 PHP 脚本中可以调用set_limit_time()函数覆盖这个设置。
假设我们想要生成报告，并把结果制作成 PDF 文件，这个任务可能要花 10 分钟才能完成，而我们肯定不想让 PHP 请求等待 10 分钟，我们应该单独编写一个 PHP 文件，让其在单独的后台进程中执行，Web 应用只需几毫秒就可以派生一个单独的后台进程，然后返回 HTTP 响应。
实际上，我们在跑需要消耗大量时间来完成的任务，一般采用后台进程方式，比如我们可以使用PHP的swoole扩展来生成报表、批量发送邮件耗时长的任务。
PHP默认的情况是将会话产生的信息存在磁盘中，例如所谓的session信息。在创建和读取session时，都会对磁盘进行I/O操作，读写磁盘其实是比较耗时的一个操作。并且session不方便做分布式应用的会话机制处理。推荐可以放在Redis、memcached这样的内存性服务中，读写速度快，并且可以做分布式会话机制处理。
下面举例将session这样的信息，存储在memcached内存中。
session.save_handler = "memcached" session.save_path = "服务地址:端口号"
如果是在较少的块中发送更多数据，而不是在较多的块中发送较少的数据，那么网络的效率会更高，也就是说，在较少的片段中把内容传递给访问者的浏览器，能减少 HTTP 请求总数。
因此，我们要让 PHP 缓冲输出，默认情况下，PHP 已经启用了输出缓冲功能，PHP 缓冲 4096 字节的输出之后才会把内容发送给 Web 服务器，推荐配置如下：
output_buffering = 4096 implicit_flush = false
如果想要修改输出缓冲区的大小，确保使用的值是4（32位系统）或8（64位系统）的倍数。
open_basedir：使用open_basedir选项能够控制PHP脚本只能访问指定的目录，这样能够避免PHP脚本访问不应该访问的文件，一定程度上限制了phpshell的危害。我们一般可以设置为只能访问网站目录：
open_basedir = /data/www
disable_functions：一般我们要禁止系统函数和禁止任何文件和目录的操作，如：
disable_functions = '.....'
expose_php = Off：将此项设置为false即不会再header头输出PHP版本信息。
display_errors = Off：生产环境中，我们应该禁止错误提示，如果是本地开发环境，可以设置为On。
log_errors = On：建议在关闭display_errors后能够把错误信息记录下来，便于查找服务器运行的原因。
error_log：设置PHP错误日志存放的目录。
推荐学习：《PHP视频教程》
The above is the detailed content of How to optimize PHP to improve high concurrency?. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
