1. 项目概述PHP方案的容量规划到底在规划什么我最早接触“php方案 容量规划”这个词是被一位朋友拉去救火的。当时某公司上线一个促销活动页PHP后台在活动首日就挂了数据库被打满PHP-FPM进程全部阻塞在MySQL查询上页面直接超时。事后复盘问题根本不是代码写得差而是压根没做过容量规划——预估流量、进程数、数据库连接数全凭感觉。容量规划说白了就是回答三个问题系统能扛多少流量流量翻倍时要不要加机器加几台才够对PHP方案来说还要多算一层PHP-FPM进程池的规模、每个进程吃多少内存、MySQL连接数够不够分配、Redis是不是先扛不住。它不是上线前临时算一算就完事而是整个系统生命周期里持续要做的功课。这篇内容适合谁看不适合只看网上的速成教程就想搞定线上高并发的人适合那些已经用PHP写过业务系统、遇到过服务器CPU飙到100%、MySQL连接数打满、或者老板突然说“下个月流量翻三倍”却不知道怎么评估的人。我会把容量规划拆成一套可落地的做法从预估模型到压测实操从参数计算到瓶颈排查全部还原我实际踩坑之后沉淀下来的流程。需要先说清楚一条原则容量规划不是精确预测而是基于合理假设做成本与风险之间的平衡。你永远无法精准算出一个未知流量体系下的配置但你可以给出一份有依据的估算再通过压测验证最后留出足够的冗余兜底。这套方法论换到任何语言、任何框架都成立PHP只是其中比较典型的一种方案——因为它的进程模型、状态管理和部署方式有不少容量计算的特有门道。2. 容量规划的完整设计思路与量化模型2.1 先算业务指标再算技术指标很多人在容量规划时直接跳到服务器配置关心 CPU 核数、内存大小这是本末倒置。正确的顺序是先明确业务指标再把这些指标翻译成技术负载。业务指标通常是这几个DAU日活用户数、PV页面浏览量、核心接口的调用量、关键操作的转化率。举个例子一个资讯类站点DAU是50万人均浏览20个页面那么总PV就是1000万。如果这些PV集中在每天4个小时的活跃时段里粗略估算每秒请求数QPS就是1000万 ÷ 4 ÷ 3600 ≈ 694 QPS。再考虑峰值系数一般取1.5到3倍那峰值QPS大约在1000到2000之间。技术指标就是从这个QPS倒推出来的单台Web服务器能处理的PHP请求数、每个请求平均耗时、数据库能支撑的查询量、Redis每秒能处理的读写次数、带宽够不够传完所有响应内容。我见过一个比较常见的失误只按平均QPS做规划忽略了流量尖峰。比如正常200 QPS一到大促变成2000 QPS这就是10倍差距。这类场景必须在预估时单独打上峰值系数宁可冗余不能裸奔。2.2 单机服务能力的评估方法单台机器能抗多少QPS不是拍脑袋想出来的。最笨也最可靠的方法就是压测但压测之前可以先做一轮理论估算心里有个底。先估算PHP-FPM进程池的容量。假设服务器有8核CPU、16GB内存给PHP-FPM分配8GB内存每个PHP-FPM进程平均占用内存40MB这是常规业务下的平均值具体要看框架和业务复杂度那么最大进程数就是8GB ÷ 40MB ≈ 200个进程。如果配置pm.max_children 100预留出缓冲空间这个值是合理的。然后是每个进程每秒能处理多少请求。假如接口平均响应时间是80ms包含PHP执行时间不包含数据库等待那每个进程每秒大约能跑 1 ÷ 0.08 12.5个请求。100个进程理论上每秒能处理1250个请求。这个数字看着不错但必须打折扣——因为响应时间会随着负载上升而恶化接口里包含数据库查询、Redis读取、外部接口调用时真实吞吐量往往只有理论值的50%到60%。这里有个需要重点解释的计算逻辑响应时间增加时单进程吞吐量下降但进程池的大小固定如果QPS超过了单机的处理上限请求就会排队队列越排越长等待时间无限拉长最后表现为“服务器卡死”。这就是容量规划里常说的拐点——负载超过某个阈值后系统性能不是缓慢下降而是直接崩溃。2.3 容量规划的几个关键参数模型我把日常用得最多的几个参数模型整理出来后面所有操作步骤都会用到这些公式。第一QPS与并发量的关系。并发量同时正在处理中的请求数 QPS × 平均响应时间。比如QPS是500平均响应时间是0.1秒那并发量就是50。这个并发量决定了需要多少个PHP-FPM进程同时工作。第二单机可用进程数。可分配内存 ÷ 单进程内存占用。这里单进程内存占用要用压测时实际观察到的值而不是ps命令显示的初始值。PHP进程处理完请求后并不会把所有内存都释放所以要取压测峰值状态下的RES内存。第三需要的机器数量。业务总QPS ÷ 单机可支撑QPS × 冗余系数。冗余系数我习惯留1.5到2倍主要考虑两点一是机器总会有故障要留出切换余量二是流量预估本身有误差至少要能扛住预估值的1.5倍才有安全感。第四数据库连接数。MySQL的max_connections默认是151如果把连接数设置得过高MySQL会消耗大量内存管理连接反而影响性能。PHP-FPM的每个进程在持有数据库连接时如果连接池设计不好100个PHP进程就可能占100个连接两个Web节点就把MySQL连接数打满了。这个问题后面单独讲非常典型。第五带宽计算。带宽 平均页面大小 × 峰值QPS × 8换算成bit。假设平均每个响应50KB峰值QPS是1000那每秒要传50MB数据带宽需要400Mbps。很多公司服务器带宽只买了10Mbps或者20Mbps如果忘了算带宽服务器和数据库都好好的带宽却成了瓶颈用户会感觉页面加载特别慢。这些模型组合起来就是一套容量规划的基础框架。先把这些公式弄清楚后面所有的压测操作才有参考基准。2.4 CPU密集还是IO密集的定性判断PHP方案特别需要区分请求是CPU密集还是IO密集。这一点直接影响进程池大小的设置和机器的选型。CPU密集型的请求比如图像处理、复杂加密计算、大量的数组遍历这类请求吃的是CPU时间片。如果接口平均执行时间200ms其中150ms都在算那说明是CPU密集。这种场景下进程数并不需要特别多因为CPU计算本身是串行资源开再多的进程也会在CPU调度上排队。相反如果接口平均执行时间200ms里有170ms都在等数据库、等Redis、等外部HTTP响应那属于IO密集进程池可以开大一点因为进程大部分时间都在等待CPU利用率反而不高。这个判断影响重大。我曾经见过一个团队把pm.max_children从100调高到300结果CPU占用率反而降了——就因为他们的业务80%的时间都在等数据库返回调高进程数充分利用了IO等待时间整体吞吐量提升但每个请求的CPU使用率本来就低所以总CPU占用没有线性上升。当然进程数也不是越高越好后面实操部分会讲怎样找到拐点。3. 核心细节解析PHP方案里几个容量规划的关键动作3.1 PHP-FPM进程池配置不是拍脑袋写出来的PHP-FPM的配置直接决定容量边界核心参数是这几个pm.max_children、pm.start_servers、pm.min_spare_servers、pm.max_spare_servers、pm.max_requests。pm.max_children是进程池最大进程数这是容量规划里最核心的数值。计算方法前面已经给了可用内存 ÷ 单进程平均占用内存。但是有一个非常关键的细节——要预留操作系统本身的内存和MySQL、Redis、Nginx这些常驻服务的内存不能把整台机器的内存全分给PHP-FPM。比如16GB的机器系统本身占1GBMySQL占4GBRedis占2GBNginx占0.5GB剩下8.5GB才给PHP-FPM。如果不预留一旦流量上来进程内存总和超过物理内存系统开始用swap性能直接雪崩。pm.max_requests让每个PHP进程处理一定数量的请求后自动重启这是防止内存泄漏累积的有效手段。我习惯设置1000到5000之间具体看业务对内存的消耗速度。设置太小的缺点是频繁重启进程会带来额外开销设置太大的缺点是内存泄漏的进程会一直留在池子里。注意修改完PHP-FPM配置后不能用systemctl restart php-fpm这种硬重启方式会让所有正在处理的请求瞬间断掉。应该用php-fpm的reload方式平滑重启它会等当前请求处理完再回收进程。3.2 数据库连接数的估算与保护PHP方案里数据库容量规划经常被忽略但实际线上故障大多数都是从数据库连接数打满开始的。场景推演一下你有2台Web服务器每台配置了100个PHP-FPM进程MySQL的max_connections是400。假如PHP没有使用连接池大多数传统PHP项目确实没有每个PHP进程在处理请求时打开一个MySQL连接高峰期200个PHP进程同时请求数据库连接数瞬间到200。如果这时候数据库执行慢查询单条SQL耗时2秒那么这200个连接会因为SQL慢而一直占着不放新的请求进来继续尝试连接MySQL连接数涨到400上限之后所有连接请求直接报“Too many connections”错误。这个场景里连接数爆掉的根本原因是慢查询占用了连接不释放容量规划时就要先评估两条防线第一条防线控制慢查询的比例。容量规划里要给数据库估算一个“吞吐能力基线”。MySQL单实例常规配置下简单主键查询的QPS能到3000到5000但一旦涉及多表join、模糊查询、排序这个数值会急剧下降。所以容量规划不是只看Web层必须把核心接口的SQL执行时间纳入统计定位哪些SQL是慢查询提前优化。第二条防线限制MySQL最大连接数同时在前端做保护。把max_connections设置到800甚至更高可以延缓爆掉的时间但不能根治问题。更有效的做法是PHP层做并发控制——如果预计核心接口的并发不会超过100就可以用信号量或Redis锁限制同时执行SQL的进程数量让超出的请求排队等待而不是全部挤向数据库。3.3 状态存储的容量规划Session的PHP方案PHP的Session如果默认存文件容量规划里会多出一个让人头疼的维度单机Session存储。默认配置下PHP Session文件存在各台Web服务器的本地磁盘上这就带来两个问题。第一个是内存浪费。文件Session的存储通常不会占太多内存但它限制了系统扩展性。如果你需要从1台扩展到3台用户的Session会随机落在不同机器上登录状态频繁丢失。很多团队用Redis存Session解决这个问题这不仅是为了体验更是为了容量规划——把Session的存储与Web服务器解耦Web服务器无状态化之后扩容才能变成单纯加机器的事。第二个问题是文件句柄数。PHP文件Session的会话保持默认的GC概率超大流量时会产生大量Session文件磁盘IO和inode消耗都会有压力。用Redis替换文件Session后这个压力就转移到Redis的容量上。存储容量的估算公式是峰值在线用户数 × 每个Session平均大小。比如同时在线10万人每个Session存40KB就需要4GB的Redis内存。注意这是基数Redis还要留出缓冲通常按1.5倍预留。3.4 扩展性设计从单机到多机的容量跃迁容量规划的终极目标是让系统具备水平扩展能力而不是把所有流量都压在一台机器上。PHP方案的扩展路径一般经历三个阶段单机阶段、分离阶段、集群阶段。单机阶段就是一台机器跑Web、数据库、Redis全栈适合日请求量在几十万的系统。分离阶段把MySQL放到独立机器Redis放到独立机器Web服务器保留一台适合日请求量几百万的系统。集群阶段是N台Web服务器 独立MySQL主从 Redis集群适合日请求量千万以上的系统。容量规划的意义就在于你得提前知道目前处在哪个阶段并且在流量增长之前就准备好演进路线。比如你现在是单机阶段预估明年流量增长3倍那就得提前摸清楚MySQL数据量和Redis内存占用评估是否需要提前拆库拆缓存。我在实际项目中见过不少团队因为前期没做容量规划流量涨到一定程度后被迫在深夜紧急扩容各种配置不一致、数据不一致的问题全部暴露出来。所以规划不是写文档交差而是要让系统具备可预期的扩容路径。4. 实操过程一次完整的PHP容量规划与压测实录4.1 设定业务模型这次规划要满足什么目标我用最近接手的一次调优来做完整演示。背景是某后台管理系统技术栈是PHP MySQL Redis部署在一台8核16G的服务器上。业务场景是某个报表查询接口平均每天调用量20万次集中在工作日上午9点到11点。先建立业务模型。日调用量20万次活跃时段2小时平均QPS就是 20万 ÷ 2 ÷ 3600 ≈ 28 QPS。峰值系数取3倍峰值QPS约为84。这个负载在8核单机环境下应该不难但用户反馈高峰期接口响应时间从200ms飙升到2秒以上说明某个环节存在明显瓶颈。4.2 压测前的配置基线压测之前先把配置基线记录清楚这样才能对比优化前后效果。这台服务器上PHP-FPM配的是pmdynamicpm.max_children150pm.start_servers50pm.max_spare_servers100。MySQL的max_connections300没有开启慢查询日志。Nginx的worker_processes8worker_connections4096。单看这些配置max_children150放在16G内存的机器上其实偏高。假设每个PHP进程平均占用100MBPHP业务项目加载整个框架后内存占用通常不少150个进程就可能吃掉15GB内存加上MySQL和其他常驻服务内存铁定不够。压测之前我就怀疑这是第一个坑。4.3 压测工具选择与脚本准备压测我用的工具是abApache Bench也有用wrk或者JMeter。后台管理系统这个场景单个接口压测ab最快最简单nginx自带的压测也很方便。注意ab是单线程压测如果服务器性能太好单台压测机可能压不出真实上限。这时候需要几台压测机同时打或者换用wrk这种多线程工具。压测脚本里要注意设置合理的请求参数不能每个请求都打同样的数据否则容易因为MySQL查询缓存造成误判。我的经验是在压测脚本里准备一批随机的ID参数这样才能模拟真实负载。4.4 压测过程和结果数据第一轮压测没有改动任何配置直接压峰值预期的3倍QPS也就是250 QPS左右。结果非常惨烈响应时间从200ms涨到2.3秒错误率超过了10%CPU占用率100%MySQL的连接数到了280个。压测过程中查看服务器资源发现内存已经用了14.8GBswap空间也在占用。这就是典型的进程数设置过大内存超支导致系统性能直线下降。第一轮压测反映的问题非常典型把max_children从150调低到80同时检查了每个PHP进程的实际内存占用发现平均约120MB这是框架加载后PHP在真实请求压力下的实际占用和空载时的内存完全不一样。80个进程 × 120MB 9.6GB加上MySQL和其他服务约5GB16G内存刚好够用。调低进程数后开始第二轮压测。QPS 250的情况下响应时间降到了450ms。改进很明显但450ms离目标还有距离。通过慢查询日志定位到两条高耗时SQL一条统计报表数据的时候用了全表扫描一条是多表join时没有走索引。分别优化后接口CPU耗时从120ms降到30ms响应时间到了200ms左右。第三轮压测250 QPS下响应时间稳定在180ms错误率0%CPU占用率45%内存使用率70%左右整体稳定。这三轮压测下来配置就是pm.max_children80、pm.max_requests2000、MySQL慢查询阈值设为1秒、连接数降到200。4.5 容量上限与扩容判断这台机器经过调优后能支撑的天花板在哪里压测结果给我一个参考值单机在响应时间不超过500ms的前提下大约能支撑500 QPS。也就是说业务峰值84 QPS的情况下这台机器有大约6倍的余量。但要注意业务模型中的峰值系数是3倍我还要再留一倍的冗余来应对突发流量所以理论上这台机器至少还能再撑两年。如果哪天预估流量超过600 QPS扩容方案就是直接再加一台Web服务器。扩容前需要考虑的容量维度是PHP-FPM进程数只多了一倍数据库QPS是否会顶不住Redis内存需不需要加Session迁移是否已经完成。这些问题如果前期没准备好扩容就只是一个把机器加进来的动作不加进去还好加进去反而会拖垮数据库。5. 常见问题与排查技巧实录5.1 压测数据与线上数据对不上怎么办很多团队做完压测觉得单机能力很强上线后发现真实流量一来就挂怀疑压测数据造假。其实往往不是压测数据假而是压测模型和真实业务模型不匹配。最常见的问题是没有模拟真实请求的分布。压测脚本里全是同一个接口的相同参数数据库只要多跑几次缓存可能就全部命中内存里的热点数据也被TCP层缓存压测QPS一片大好。真实情况是请求的ID千差万别数据不在缓存里每一条都是磁盘读性能差距能到10倍。另一点是压测时没有做慢接口混合。真实业务里总会有几个比较慢的接口混在快接口之间慢请求占用PHP-FPM进程快请求就得等着。压测如果只打快接口进程池永远不会积压很难暴露真实问题。我自己的做法是拿线上Nginx的access.log做回放压测把真实请求分布重新打回去这样压出来的数据参考价值最高。如果没条件至少要保证压测脚本里同时混合2到3种不同耗时的接口并且参数不能是固定值。5.2 内存泄漏导致的容量误判PHP进程的内存占用在压测初期和峰值阶段完全不是一回事。空载时一个PHP进程可能只占30MB但跑了一段时间后能涨到200MB甚至更多。这不是语言层面的bug而是业务代码里常见的开销单例对象越积越多、日志缓冲区累积、用过的数组没有释放。如果没有设置pm.max_requests这些进程会一直吃内存直到系统开始swap。容量规划时要给这个“内存泄漏系数”留出余量。建议按峰值观察到的实际内存占用乘以1.3来配置max_children。另外pm.max_requests一定要设置让进程在请求数达到阈值后重启这是最直接的内存回收手段。5.3 “进程数越多越好”的认知误区有人在容量规划中认为PHP-FPM进程数开得越多越好这个观点只对了一半。进程数是IO密集型业务的有效提升手段但一旦越过物理资源的界线多开的进程反而互相抢占CPU和内存。判断进程池数量是否合理的办法很简单压测时观察CPU利用率与进程数的关系。如果进程数从50加到100CPU利用率也翻倍了说明还有余量。如果进程数加了但CPU不再上涨说明CPU已经饱和此时再增加进程只会增加上下文切换和内耗。一旦内存接近上限这个问题就必须优先处理甚至比CPU还优先。5.4 MySQL连接数打满的排查顺序遇到“Too many connections”错误我习惯的排查顺序是先看processlist里哪些SQL在跑是长时间执行的慢查询还是正常的短查询堆积查慢查询日志定位耗时最长的几个SQL看数据库当前活跃连接数和sleep连接数的比例确认连接池配置是否合理。一个比较容易被忽视的细节是sleep连接。PHP脚本执行完后有时连接不会马上断开而是进入sleep状态。如果sleep连接数占据大量连接数说明代码里数据库连接没有正确关闭或者长连接的使用方式有误。解决方法是启用MySQL的wait_timeout和interactive_timeout参数把空闲连接自动断开同时PHP端使用短连接模式请求结束后及时释放连接资源。6. 这套容量规划经验的后续扩展最后分享一个后续可以用起来的小思路。这套容量规划模型不单适用于PHP方案把它迁移到其他后端语言时只要把进程模型换成对应语言的并发模型内存占用换成对应运行时数据公式架构是通用的。比如换成Go或Java方案时线程池或协程池的容量计算逻辑可以复用这套思路数据库、Redis、带宽的规划方式几乎完全一致。我的个人体会是容量规划最大的敌人不是流量本身而是不确定性。一套能应对“流量翻倍、数据翻倍、机器减半”等场景的规划方案比追求一个精确数字更有价值。它让整个团队在面对突发情况时不慌并且知道下一步该加机器还是该优化代码。按照这套方法来至少不会在最基本的地方摔跟头。 
长河君 · 2026/10/16 10:01:23 · 阅读 1.2k PHP方案容量规划实战：从QPS模型到PHP-FPM调优
1. 项目概述PHP方案的容量规划到底在规划什么我最早接触“php方案 容量规划”这个词是被一位朋友拉去救火的。当时某公司上线一个促销活动页PHP后台在活动首日就挂了数据库被打满PHP-FPM进程全部阻塞在MySQL查询上页面直接超时。事后复盘问题根本不是代码写得差而是压根没做过容量规划——预估流量、进程数、数据库连接数全凭感觉。容量规划说白了就是回答三个问题系统能扛多少流量流量翻倍时要不要加机器加几台才够对PHP方案来说还要多算一层PHP-FPM进程池的规模、每个进程吃多少内存、MySQL连接数够不够分配、Redis是不是先扛不住。它不是上线前临时算一算就完事而是整个系统生命周期里持续要做的功课。这篇内容适合谁看不适合只看网上的速成教程就想搞定线上高并发的人适合那些已经用PHP写过业务系统、遇到过服务器CPU飙到100%、MySQL连接数打满、或者老板突然说“下个月流量翻三倍”却不知道怎么评估的人。我会把容量规划拆成一套可落地的做法从预估模型到压测实操从参数计算到瓶颈排查全部还原我实际踩坑之后沉淀下来的流程。需要先说清楚一条原则容量规划不是精确预测而是基于合理假设做成本与风险之间的平衡。你永远无法精准算出一个未知流量体系下的配置但你可以给出一份有依据的估算再通过压测验证最后留出足够的冗余兜底。这套方法论换到任何语言、任何框架都成立PHP只是其中比较典型的一种方案——因为它的进程模型、状态管理和部署方式有不少容量计算的特有门道。2. 容量规划的完整设计思路与量化模型2.1 先算业务指标再算技术指标很多人在容量规划时直接跳到服务器配置关心 CPU 核数、内存大小这是本末倒置。正确的顺序是先明确业务指标再把这些指标翻译成技术负载。业务指标通常是这几个DAU日活用户数、PV页面浏览量、核心接口的调用量、关键操作的转化率。举个例子一个资讯类站点DAU是50万人均浏览20个页面那么总PV就是1000万。如果这些PV集中在每天4个小时的活跃时段里粗略估算每秒请求数QPS就是1000万 ÷ 4 ÷ 3600 ≈ 694 QPS。再考虑峰值系数一般取1.5到3倍那峰值QPS大约在1000到2000之间。技术指标就是从这个QPS倒推出来的单台Web服务器能处理的PHP请求数、每个请求平均耗时、数据库能支撑的查询量、Redis每秒能处理的读写次数、带宽够不够传完所有响应内容。我见过一个比较常见的失误只按平均QPS做规划忽略了流量尖峰。比如正常200 QPS一到大促变成2000 QPS这就是10倍差距。这类场景必须在预估时单独打上峰值系数宁可冗余不能裸奔。2.2 单机服务能力的评估方法单台机器能抗多少QPS不是拍脑袋想出来的。最笨也最可靠的方法就是压测但压测之前可以先做一轮理论估算心里有个底。先估算PHP-FPM进程池的容量。假设服务器有8核CPU、16GB内存给PHP-FPM分配8GB内存每个PHP-FPM进程平均占用内存40MB这是常规业务下的平均值具体要看框架和业务复杂度那么最大进程数就是8GB ÷ 40MB ≈ 200个进程。如果配置pm.max_children 100预留出缓冲空间这个值是合理的。然后是每个进程每秒能处理多少请求。假如接口平均响应时间是80ms包含PHP执行时间不包含数据库等待那每个进程每秒大约能跑 1 ÷ 0.08 12.5个请求。100个进程理论上每秒能处理1250个请求。这个数字看着不错但必须打折扣——因为响应时间会随着负载上升而恶化接口里包含数据库查询、Redis读取、外部接口调用时真实吞吐量往往只有理论值的50%到60%。这里有个需要重点解释的计算逻辑响应时间增加时单进程吞吐量下降但进程池的大小固定如果QPS超过了单机的处理上限请求就会排队队列越排越长等待时间无限拉长最后表现为“服务器卡死”。这就是容量规划里常说的拐点——负载超过某个阈值后系统性能不是缓慢下降而是直接崩溃。2.3 容量规划的几个关键参数模型我把日常用得最多的几个参数模型整理出来后面所有操作步骤都会用到这些公式。第一QPS与并发量的关系。并发量同时正在处理中的请求数 QPS × 平均响应时间。比如QPS是500平均响应时间是0.1秒那并发量就是50。这个并发量决定了需要多少个PHP-FPM进程同时工作。第二单机可用进程数。可分配内存 ÷ 单进程内存占用。这里单进程内存占用要用压测时实际观察到的值而不是ps命令显示的初始值。PHP进程处理完请求后并不会把所有内存都释放所以要取压测峰值状态下的RES内存。第三需要的机器数量。业务总QPS ÷ 单机可支撑QPS × 冗余系数。冗余系数我习惯留1.5到2倍主要考虑两点一是机器总会有故障要留出切换余量二是流量预估本身有误差至少要能扛住预估值的1.5倍才有安全感。第四数据库连接数。MySQL的max_connections默认是151如果把连接数设置得过高MySQL会消耗大量内存管理连接反而影响性能。PHP-FPM的每个进程在持有数据库连接时如果连接池设计不好100个PHP进程就可能占100个连接两个Web节点就把MySQL连接数打满了。这个问题后面单独讲非常典型。第五带宽计算。带宽 平均页面大小 × 峰值QPS × 8换算成bit。假设平均每个响应50KB峰值QPS是1000那每秒要传50MB数据带宽需要400Mbps。很多公司服务器带宽只买了10Mbps或者20Mbps如果忘了算带宽服务器和数据库都好好的带宽却成了瓶颈用户会感觉页面加载特别慢。这些模型组合起来就是一套容量规划的基础框架。先把这些公式弄清楚后面所有的压测操作才有参考基准。2.4 CPU密集还是IO密集的定性判断PHP方案特别需要区分请求是CPU密集还是IO密集。这一点直接影响进程池大小的设置和机器的选型。CPU密集型的请求比如图像处理、复杂加密计算、大量的数组遍历这类请求吃的是CPU时间片。如果接口平均执行时间200ms其中150ms都在算那说明是CPU密集。这种场景下进程数并不需要特别多因为CPU计算本身是串行资源开再多的进程也会在CPU调度上排队。相反如果接口平均执行时间200ms里有170ms都在等数据库、等Redis、等外部HTTP响应那属于IO密集进程池可以开大一点因为进程大部分时间都在等待CPU利用率反而不高。这个判断影响重大。我曾经见过一个团队把pm.max_children从100调高到300结果CPU占用率反而降了——就因为他们的业务80%的时间都在等数据库返回调高进程数充分利用了IO等待时间整体吞吐量提升但每个请求的CPU使用率本来就低所以总CPU占用没有线性上升。当然进程数也不是越高越好后面实操部分会讲怎样找到拐点。3. 核心细节解析PHP方案里几个容量规划的关键动作3.1 PHP-FPM进程池配置不是拍脑袋写出来的PHP-FPM的配置直接决定容量边界核心参数是这几个pm.max_children、pm.start_servers、pm.min_spare_servers、pm.max_spare_servers、pm.max_requests。pm.max_children是进程池最大进程数这是容量规划里最核心的数值。计算方法前面已经给了可用内存 ÷ 单进程平均占用内存。但是有一个非常关键的细节——要预留操作系统本身的内存和MySQL、Redis、Nginx这些常驻服务的内存不能把整台机器的内存全分给PHP-FPM。比如16GB的机器系统本身占1GBMySQL占4GBRedis占2GBNginx占0.5GB剩下8.5GB才给PHP-FPM。如果不预留一旦流量上来进程内存总和超过物理内存系统开始用swap性能直接雪崩。pm.max_requests让每个PHP进程处理一定数量的请求后自动重启这是防止内存泄漏累积的有效手段。我习惯设置1000到5000之间具体看业务对内存的消耗速度。设置太小的缺点是频繁重启进程会带来额外开销设置太大的缺点是内存泄漏的进程会一直留在池子里。注意修改完PHP-FPM配置后不能用systemctl restart php-fpm这种硬重启方式会让所有正在处理的请求瞬间断掉。应该用php-fpm的reload方式平滑重启它会等当前请求处理完再回收进程。3.2 数据库连接数的估算与保护PHP方案里数据库容量规划经常被忽略但实际线上故障大多数都是从数据库连接数打满开始的。场景推演一下你有2台Web服务器每台配置了100个PHP-FPM进程MySQL的max_connections是400。假如PHP没有使用连接池大多数传统PHP项目确实没有每个PHP进程在处理请求时打开一个MySQL连接高峰期200个PHP进程同时请求数据库连接数瞬间到200。如果这时候数据库执行慢查询单条SQL耗时2秒那么这200个连接会因为SQL慢而一直占着不放新的请求进来继续尝试连接MySQL连接数涨到400上限之后所有连接请求直接报“Too many connections”错误。这个场景里连接数爆掉的根本原因是慢查询占用了连接不释放容量规划时就要先评估两条防线第一条防线控制慢查询的比例。容量规划里要给数据库估算一个“吞吐能力基线”。MySQL单实例常规配置下简单主键查询的QPS能到3000到5000但一旦涉及多表join、模糊查询、排序这个数值会急剧下降。所以容量规划不是只看Web层必须把核心接口的SQL执行时间纳入统计定位哪些SQL是慢查询提前优化。第二条防线限制MySQL最大连接数同时在前端做保护。把max_connections设置到800甚至更高可以延缓爆掉的时间但不能根治问题。更有效的做法是PHP层做并发控制——如果预计核心接口的并发不会超过100就可以用信号量或Redis锁限制同时执行SQL的进程数量让超出的请求排队等待而不是全部挤向数据库。3.3 状态存储的容量规划Session的PHP方案PHP的Session如果默认存文件容量规划里会多出一个让人头疼的维度单机Session存储。默认配置下PHP Session文件存在各台Web服务器的本地磁盘上这就带来两个问题。第一个是内存浪费。文件Session的存储通常不会占太多内存但它限制了系统扩展性。如果你需要从1台扩展到3台用户的Session会随机落在不同机器上登录状态频繁丢失。很多团队用Redis存Session解决这个问题这不仅是为了体验更是为了容量规划——把Session的存储与Web服务器解耦Web服务器无状态化之后扩容才能变成单纯加机器的事。第二个问题是文件句柄数。PHP文件Session的会话保持默认的GC概率超大流量时会产生大量Session文件磁盘IO和inode消耗都会有压力。用Redis替换文件Session后这个压力就转移到Redis的容量上。存储容量的估算公式是峰值在线用户数 × 每个Session平均大小。比如同时在线10万人每个Session存40KB就需要4GB的Redis内存。注意这是基数Redis还要留出缓冲通常按1.5倍预留。3.4 扩展性设计从单机到多机的容量跃迁容量规划的终极目标是让系统具备水平扩展能力而不是把所有流量都压在一台机器上。PHP方案的扩展路径一般经历三个阶段单机阶段、分离阶段、集群阶段。单机阶段就是一台机器跑Web、数据库、Redis全栈适合日请求量在几十万的系统。分离阶段把MySQL放到独立机器Redis放到独立机器Web服务器保留一台适合日请求量几百万的系统。集群阶段是N台Web服务器 独立MySQL主从 Redis集群适合日请求量千万以上的系统。容量规划的意义就在于你得提前知道目前处在哪个阶段并且在流量增长之前就准备好演进路线。比如你现在是单机阶段预估明年流量增长3倍那就得提前摸清楚MySQL数据量和Redis内存占用评估是否需要提前拆库拆缓存。我在实际项目中见过不少团队因为前期没做容量规划流量涨到一定程度后被迫在深夜紧急扩容各种配置不一致、数据不一致的问题全部暴露出来。所以规划不是写文档交差而是要让系统具备可预期的扩容路径。4. 实操过程一次完整的PHP容量规划与压测实录4.1 设定业务模型这次规划要满足什么目标我用最近接手的一次调优来做完整演示。背景是某后台管理系统技术栈是PHP MySQL Redis部署在一台8核16G的服务器上。业务场景是某个报表查询接口平均每天调用量20万次集中在工作日上午9点到11点。先建立业务模型。日调用量20万次活跃时段2小时平均QPS就是 20万 ÷ 2 ÷ 3600 ≈ 28 QPS。峰值系数取3倍峰值QPS约为84。这个负载在8核单机环境下应该不难但用户反馈高峰期接口响应时间从200ms飙升到2秒以上说明某个环节存在明显瓶颈。4.2 压测前的配置基线压测之前先把配置基线记录清楚这样才能对比优化前后效果。这台服务器上PHP-FPM配的是pmdynamicpm.max_children150pm.start_servers50pm.max_spare_servers100。MySQL的max_connections300没有开启慢查询日志。Nginx的worker_processes8worker_connections4096。单看这些配置max_children150放在16G内存的机器上其实偏高。假设每个PHP进程平均占用100MBPHP业务项目加载整个框架后内存占用通常不少150个进程就可能吃掉15GB内存加上MySQL和其他常驻服务内存铁定不够。压测之前我就怀疑这是第一个坑。4.3 压测工具选择与脚本准备压测我用的工具是abApache Bench也有用wrk或者JMeter。后台管理系统这个场景单个接口压测ab最快最简单nginx自带的压测也很方便。注意ab是单线程压测如果服务器性能太好单台压测机可能压不出真实上限。这时候需要几台压测机同时打或者换用wrk这种多线程工具。压测脚本里要注意设置合理的请求参数不能每个请求都打同样的数据否则容易因为MySQL查询缓存造成误判。我的经验是在压测脚本里准备一批随机的ID参数这样才能模拟真实负载。4.4 压测过程和结果数据第一轮压测没有改动任何配置直接压峰值预期的3倍QPS也就是250 QPS左右。结果非常惨烈响应时间从200ms涨到2.3秒错误率超过了10%CPU占用率100%MySQL的连接数到了280个。压测过程中查看服务器资源发现内存已经用了14.8GBswap空间也在占用。这就是典型的进程数设置过大内存超支导致系统性能直线下降。第一轮压测反映的问题非常典型把max_children从150调低到80同时检查了每个PHP进程的实际内存占用发现平均约120MB这是框架加载后PHP在真实请求压力下的实际占用和空载时的内存完全不一样。80个进程 × 120MB 9.6GB加上MySQL和其他服务约5GB16G内存刚好够用。调低进程数后开始第二轮压测。QPS 250的情况下响应时间降到了450ms。改进很明显但450ms离目标还有距离。通过慢查询日志定位到两条高耗时SQL一条统计报表数据的时候用了全表扫描一条是多表join时没有走索引。分别优化后接口CPU耗时从120ms降到30ms响应时间到了200ms左右。第三轮压测250 QPS下响应时间稳定在180ms错误率0%CPU占用率45%内存使用率70%左右整体稳定。这三轮压测下来配置就是pm.max_children80、pm.max_requests2000、MySQL慢查询阈值设为1秒、连接数降到200。4.5 容量上限与扩容判断这台机器经过调优后能支撑的天花板在哪里压测结果给我一个参考值单机在响应时间不超过500ms的前提下大约能支撑500 QPS。也就是说业务峰值84 QPS的情况下这台机器有大约6倍的余量。但要注意业务模型中的峰值系数是3倍我还要再留一倍的冗余来应对突发流量所以理论上这台机器至少还能再撑两年。如果哪天预估流量超过600 QPS扩容方案就是直接再加一台Web服务器。扩容前需要考虑的容量维度是PHP-FPM进程数只多了一倍数据库QPS是否会顶不住Redis内存需不需要加Session迁移是否已经完成。这些问题如果前期没准备好扩容就只是一个把机器加进来的动作不加进去还好加进去反而会拖垮数据库。5. 常见问题与排查技巧实录5.1 压测数据与线上数据对不上怎么办很多团队做完压测觉得单机能力很强上线后发现真实流量一来就挂怀疑压测数据造假。其实往往不是压测数据假而是压测模型和真实业务模型不匹配。最常见的问题是没有模拟真实请求的分布。压测脚本里全是同一个接口的相同参数数据库只要多跑几次缓存可能就全部命中内存里的热点数据也被TCP层缓存压测QPS一片大好。真实情况是请求的ID千差万别数据不在缓存里每一条都是磁盘读性能差距能到10倍。另一点是压测时没有做慢接口混合。真实业务里总会有几个比较慢的接口混在快接口之间慢请求占用PHP-FPM进程快请求就得等着。压测如果只打快接口进程池永远不会积压很难暴露真实问题。我自己的做法是拿线上Nginx的access.log做回放压测把真实请求分布重新打回去这样压出来的数据参考价值最高。如果没条件至少要保证压测脚本里同时混合2到3种不同耗时的接口并且参数不能是固定值。5.2 内存泄漏导致的容量误判PHP进程的内存占用在压测初期和峰值阶段完全不是一回事。空载时一个PHP进程可能只占30MB但跑了一段时间后能涨到200MB甚至更多。这不是语言层面的bug而是业务代码里常见的开销单例对象越积越多、日志缓冲区累积、用过的数组没有释放。如果没有设置pm.max_requests这些进程会一直吃内存直到系统开始swap。容量规划时要给这个“内存泄漏系数”留出余量。建议按峰值观察到的实际内存占用乘以1.3来配置max_children。另外pm.max_requests一定要设置让进程在请求数达到阈值后重启这是最直接的内存回收手段。5.3 “进程数越多越好”的认知误区有人在容量规划中认为PHP-FPM进程数开得越多越好这个观点只对了一半。进程数是IO密集型业务的有效提升手段但一旦越过物理资源的界线多开的进程反而互相抢占CPU和内存。判断进程池数量是否合理的办法很简单压测时观察CPU利用率与进程数的关系。如果进程数从50加到100CPU利用率也翻倍了说明还有余量。如果进程数加了但CPU不再上涨说明CPU已经饱和此时再增加进程只会增加上下文切换和内耗。一旦内存接近上限这个问题就必须优先处理甚至比CPU还优先。5.4 MySQL连接数打满的排查顺序遇到“Too many connections”错误我习惯的排查顺序是先看processlist里哪些SQL在跑是长时间执行的慢查询还是正常的短查询堆积查慢查询日志定位耗时最长的几个SQL看数据库当前活跃连接数和sleep连接数的比例确认连接池配置是否合理。一个比较容易被忽视的细节是sleep连接。PHP脚本执行完后有时连接不会马上断开而是进入sleep状态。如果sleep连接数占据大量连接数说明代码里数据库连接没有正确关闭或者长连接的使用方式有误。解决方法是启用MySQL的wait_timeout和interactive_timeout参数把空闲连接自动断开同时PHP端使用短连接模式请求结束后及时释放连接资源。6. 这套容量规划经验的后续扩展最后分享一个后续可以用起来的小思路。这套容量规划模型不单适用于PHP方案把它迁移到其他后端语言时只要把进程模型换成对应语言的并发模型内存占用换成对应运行时数据公式架构是通用的。比如换成Go或Java方案时线程池或协程池的容量计算逻辑可以复用这套思路数据库、Redis、带宽的规划方式几乎完全一致。我的个人体会是容量规划最大的敌人不是流量本身而是不确定性。一套能应对“流量翻倍、数据翻倍、机器减半”等场景的规划方案比追求一个精确数字更有价值。它让整个团队在面对突发情况时不慌并且知道下一步该加机器还是该优化代码。按照这套方法来至少不会在最基本的地方摔跟头。