千万级数据并发如何处理？进入学习
PHP相对其他的编译性语言，最大的缺点在于每次请求都会去做一些模块解析，真正执行的是work进程。work进程的开启需要消耗更多的资源。同时，来一个请求都会去重新解析一些代码，导致重复解析。
对于PHP的优化，可以重点充这方面去考虑进行优化。
运行 PHP 时需要关心每个 PHP 进程要使用多少内存，php.ini 中的memory_limit设置用于设定单个 PHP 进程可以使用的系统内存最大值。
这个设置的默认值是 128M，这对于大多数中小型 PHP 应用来说或许合适，不过，如果运行的是微型 PHP 应用，可以降低这个值，以便节省系统资源，反之，如果运行的是内存集中型 PHP 应用，可以增加这个值。这个值的大小由可用的系统内存决定，确定给 PHP 分配多少值是一门艺术，决定给 PHP 分配多少内存，以及能负担起多少个 PHP-FPM 进程时，可以根据以下维度信息进行判断：
一共可以分配给 PHP 多少内存？以一个 2G 内存的 VPS 为例，这台设备中可能还运行了其他进程，如 MySQL、Nginx 等，那么留 512M 给 PHP 是合适的。
每个 PHP 进程平均耗费多少内存？这个要监控进程的内存使用量，可以使用命令行命令top，也可以在 PHP 脚本中调用 memory_get_peak_usage() 函数，不管使用哪种方式，都要多次运行同一个脚本，然后取内存消耗的平均值。
能负担起多少个 PHP-FPM 进程？假设我给 PHP 分配了 512M 内存，每个 PHP 进程平均耗费 15M 内存，那么可以负担起 34 个 PHP-FPM 进程。
有足够的系统资源吗？最后还需要确认有足够的系统资源运行 PHP 应用并处理预期的流量。具体的PHP配置信息可以参考php-fpm.config配置文件。
; 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有三种运行模式，分别是固定进程数、按需进程数、完全动态进程数。
按需进程数，默认初始化几个进程数，如果进去量过大，动态创建一些新的进程数，等请求结束之后，新创建的进程数在销毁掉。
固定进程数，默认固定几个进程，如果进程数不够的情况时，新的请求处于等待中，直到其他的进程处理完毕才会处理新的请求。
完全动态进程数，表示完全由请求量控制，来一个请求创建一个进程，处理完毕在销毁掉。
确定要分配多少内存后，就可以配置 PHP 的 Zend OPcache 扩展。OPcache主要是将一些代码解析成字节码，在后续的请求中就无需重复去解析、编译这部分代码。减少编译、解析的过程，也能提高PHP的处理速度。
PHP5.5.0+内置了这个扩展，下面罗列几项必要的配置信息：
opcache.memory_consumption = 64：为操作码缓存分配的内存（单位是MB），分配的内存量应该可以保存应用中所有 PHP 脚本编译得到的操作码，这个值根据应用的体量可以设置成不同大小的值。
opcache.interned_strings_buffer = 16：用来存储驻留字符串的内存量（单位是MB），什么是驻留字符串呢？PHP 解释器在背后会找到相同字符串的多个实例，把这个字符串保存在内存中，如果再次使用相同的字符串，PHP 解释器会使用指针，这么做的目的是节省内存。默认情况下，PHP 驻留字符串会隔离在各个 PHP 进程中，这个设置能让 PHP-FPM 进程池把所有进程驻留字符串存储到共享的缓冲区中，以便在 PHP-FPM 进程池中的多个进程之间引用驻留字符串，这样能节省更多内存。
opcache.max_accelerated_files = 4000：操作码缓存中最多能存储多少个 PHP 脚本，这个值的区间是 2000 到 100000 之间，这个值一定要比 PHP 应用中的文件数大。
opcache.validate_timestamps = 1：这个设置的值为1时，经过一段时间后 PHP 会检查 PHP 脚本的内容是否有变化，检查的时间间隔由opcache.revalidate_freq设置指定。如果这个设置的值为0，PHP 不会检查 PHP 脚本的内容是否有变化，我们必须自己动手清除缓存的操作码。建议在开发环境中设置为1，生产环境中设置为0。
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
set_limit_time()函数覆盖这个设置。假设我们想要生成报告，并把结果制作成 PDF 文件，这个任务可能要花 10 分钟才能完成，而我们肯定不想让 PHP 请求等待 10 分钟，我们应该单独编写一个 PHP 文件，让其在单独的后台进程中执行，Web 应用只需几毫秒就可以派生一个单独的后台进程，然后返回 HTTP 响应。
实际上，我们在跑需要消耗大量时间来完成的任务，一般采用后台进程方式，比如我们可以使用PHP的swoole扩展来生成报表、批量发送邮件耗时长的任务。
PHP默认的情况是将会话产生的信息存在磁盘中，例如所谓的session信息。在创建和读取session时，都会对磁盘进行I/O操作，读写磁盘其实是比较耗时的一个操作。并且session不方便做分布式应用的会话机制处理。