接手过不少PHP项目也帮同行排查过线上故障我最大的感受是性能问题最忌讳“猜”。之前有个后台列表页从点击到出数据要3秒多高峰期直接卡死。我做的第一件事不是打开IDE撸代码而是把Nginx访问日志、PHP-FPM慢日志和MySQL慢查询日志三样东西摆在桌面上按顺序一点点往下剥。为什么要这么做因为“慢”可能发生在任何一个环节可能是代码写得烂也极有可能是数据库没走索引、FPM进程池配置不合理、缓存策略缺失甚至是前端资源加载拖了后腿。如果你一上来就埋头改函数运气好能挤出三五毫秒运气不好折腾一晚上毫无变化。这篇文章就是把我日常做PHP性能分析与调优的完整思路梳理一遍从定位瓶颈到实战优化每个环节都尽量给出能直接照着用的命令、配置和判断方法。适合正在为线上接口变慢发愁的开发者也适合刚接触性能优化、想建立系统排查思路的朋友。1. 先别急着改代码搞清楚慢的到底是哪一层1.1 用户说“慢”真的只是代码慢吗一次HTTP请求从用户浏览器到服务器再返回链路特别长浏览器发起请求、DNS解析、网络传输、Nginx接收、PHP-FPM处理、PHP框架运行、访问MySQL/Redis、外部API调用、模板渲染、响应回传、浏览器加载资源并渲染页面。你自己用浏览器访问一个页面感觉“卡”的体感时间是从点击到页面完整呈现的总时长。但这段总时长里PHP代码执行往往只占一小部分。我见过不少案例用户抱怨接口慢实际抓包一看是某个静态资源被外部引用拖到好几秒还有人折腾半天代码优化最后发现是Nginx配置里没开压缩光传输就占了大部分时间。所以第一步永远是先分清楚慢在哪一层。1.2 用手头的工具先把时间账算清楚浏览器开发者工具是最快的入手点打开Network面板刷新页面看瀑布图里每个请求的耗时分布。这里有个关键指标叫TTFBTime To First Byte指从发请求到收到响应第一个字节的时间。判断逻辑很简单TTFB高比如超过1秒说明服务端处理是重灾区问题大概率出在PHP、数据库或者Nginx配置上。TTFB低但整个页面加载慢说明重点在静态资源数量、资源体积、渲染阻塞这些前端因素上。网络本身慢比如请求在Waiting阶段耗时异常可能是网络链路、DNS解析或代理的问题。如果在服务器上我更习惯用curl直接看接口耗时分解。在执行环境里敲这样一条命令curl -o /dev/null -s -w DNS:%{time_namelookup} 连接:%{time_connect} TTFB:%{time_starttransfer} 总时间:%{time_total}\n https://api.example.com/orders/list返回结果里每一项都对应一个阶段DNS解析多久、建立连接多久、服务端处理到返回首个字节多久、整体多久。哪个环节异常一目了然。TTFB高就锁定服务端随后进入下一步排查。1.3 别把精力浪费在“看起来很慢”的代码上很多人一提起性能调优就喜欢抠字符串拼接用单引号还是双引号、foreach和for哪个快、函数调用能不能少一层。这些都属于“看起来很专业但收益极低”的改动。以PHP 7以上的性能一次普通的函数调用开销可以忽略不计真正吃掉大头的永远是外部依赖。根据我的经验真实业务里80%的性能问题集中在这几处循环内查询数据库一个列表页几百上千条记录每条都查一次累计下来就是秒级。SQL没走索引数据量一大就全表扫描。缺少缓存同一个热数据每次请求都重新计算、重新查库。框架/依赖初始化太重一个简单接口加载了几百个类。把这三类问题排查清楚收益比抠代码细节高几个数量级。所以整个调优流程应该是先测量、再定位、最后才动手改。2. 搭一套能说话的性能观测体系从日志到APM2.1 系统层面先看三张报表CPU、内存、磁盘I/O进入服务器后先别急着看代码用几条基础命令把系统状态摸一遍。第一条是top看整体负载和CPU占用重点观察php-fpm进程的数量和CPU占用率。如果worker进程数远小于请求并发CPU还有大量空闲说明瓶颈不在CPU而是进程不够、请求在排队。如果CPU跑满再配合其他工具确定是PHP代码计算密集还是SQL执行量太大。第二条是free -m看内存余量。PHP-FPM的worker进程是很吃内存的如果看到Swap使用量持续增长、系统频繁换页说明内存严重不足再好的代码也会被磁盘交换拖慢。第三条是iostat -x 1看磁盘I/O。很多团队忽略这个日志写得太猛、临时文件读写频繁、MySQL落在机械盘上都可能让请求变慢一个数量级。有一次我排查一个偶发抖动的问题最后定位是PHP错误日志每分钟写入几十兆磁盘I/O被打满改完日志级别立刻恢复。2.2 让Nginx和PHP-FPM把慢请求“吐”出来系统指标只能说明“资源吃紧”具体哪个接口慢得靠日志说话。Nginx默认的访问日志只记时间戳和URI把它扩展一下就能直接看到哪些页面耗时高。在Nginx的http块里自定义日志格式log_format timed $remote_addr [$time_local] $request $status request_time$request_time upstream_response_time$upstream_response_time; access_log /var/log/nginx/access_timed.log timed;这里request_time是Nginx处理请求的总时长upstream_response_time是后端PHP-FPM实际执行耗时。两者差距大说明耗时卡在Nginx与上游之间的排队或传输上基本一致说明是PHP本身执行慢。PHP-FPM慢日志则更直接——它能把“执行超过阈值”的请求堆栈原样打出来。修改PHP-FPM的pool配置slowlog /var/log/php-fpm-slow.log request_slowlog_timeout 2s2秒以上的请求会被记录到slowlog并且带上当时的PHP调用堆栈。这意味着一打开配置文件就能知道慢请求卡在哪个函数、哪一行。这个文件配合Nginx访问日志基本能锁定80%的线上慢接口。2.3 要不要上APM按团队规模和现状来定日志方案属于“事后知道慢”如果想看得更细、更实时可以引入APM应用性能监控工具。市面上的APM产品一般通过一个探针嵌入PHP进程把一次请求拆成框架初始化、业务代码、数据库查询、外部HTTP调用等若干片段并以火焰图或调用链的形式呈现。这对微服务、复杂调用链的排查效率提升非常明显。不过APM也不是非上不可。我的判断标准是如果项目接口数量少、调用链简单Nginx日志加PHP-FPM慢日志加Profiler足够如果项目微服务化、接口依赖多或者线上问题呈偶发性不是每次必现那上APM能省大量排查时间。选型上开源自建可以看基于采样模式实现的工具商业方案也有提供本地部署的版本。无论选哪个原则都一样探针本身的性能开销尽量低别为了监控让系统变慢。3. 用Profiler撕开代码的面具热点函数一目了然3.1 Profiler工作机制与怎么选日志能告诉你“这个请求慢”但不能直接告诉你“代码里哪个函数是元凶”。真要撕开函数级别的耗时分布得靠Profiler。Profiler大致分两种一种是采样式运行期间按固定频率采集当前正在执行的函数栈开销低适合线上环境短时间开启另一种是注入式对每个函数的进入和退出点做埋点统计数据精确但性能开销大适合开发环境。对PHP开发者来说最熟悉的注入式工具是Xdebug。本地开发环境开启profile模式的方法zend_extensionxdebug xdebug.modeprofile xdebug.output_dir/tmp/prof xdebug.profiler_output_namecachegrind.out.%t.%p配置完成后跑一次目标请求目录下会生成cachegrind格式的文件。这个文件可以用图形化工具打开也可以直接用命令行工具解析统计看到每个函数的调用次数和耗时。生产环境不建议全程开启Xdebug profile毕竟开销摆在那。我的做法是先在预发或本地复现开profiler拿到数据如果必须在线上排查用采样式工具短时间开启、拿完数据立即关掉。3.2 看懂一份Profiler报告先抓三个数字拿到Profiler报告后新手容易盯着图发呆。其实核心指标就三个调用次数一个函数被执行了多少次。如果次数上千甚至上万基本可以怀疑有循环内重复调用。自身耗时exclusive time函数体内部代码实际花掉的时间不包括调用其他函数的时间。累计耗时inclusive time本身耗时加上它内部所有调用的耗时体现该函数对整个请求的贡献。看报告时有一个很容易踩的误区某个函数的自身耗时只有几毫秒就以为不慢。但再看调用次数发现它在循环里被执行了800次累计就是秒级。有一个印象很深的案例——列表页慢得离谱Profiler显示一个SQL查询函数自身耗时只有3毫秒但调用次数被循环放大到800次累计2.4秒这才是真正的主犯。3.3 从报告到行动给热点排优先级面对一堆耗时不等的函数别眉毛胡子一把抓。我一般按三类处理自身耗时高的单个热点考虑优化算法本身检查是否在做无意义的重复计算、是否能提前break、是否能简化数据结构。调用次数高的函数考虑把循环内查询改成批量查询把重复计算结果缓存起来。累计耗时集中在下游调用的函数比如查询、外部API考虑能不能少调两次或者把逻辑下推到数据库里用一次SQL完成。第4章和第5章会展开这三类处理里最常碰到的两个战场数据库和缓存。4. 数据库往往是那只“房间里的大象”4.1 慢查询日志是最直接的证据如果Profiler显示大量时间花在SQL查询上下一步就是打开MySQL的慢查询日志。这是定位数据库瓶颈最直接的手段。修改MySQL配置一般写在my.cnf或my.inislow_query_log 1 slow_query_log_file /var/log/mysql-slow.log long_query_time 1 log_queries_not_using_indexes 1重启MySQL后执行时间超过1秒、或者没走索引的查询会被记进日志。日志积累一段时间后用自带工具归类统计mysqldumpslow -t 10 /var/log/mysql-slow.log它会把结构相似的SQL归并到一起并显示平均耗时、执行次数。按执行次数乘以单次耗时估算影响面优先处理“次数多又慢”的SQL——很多时候一条没索引的查询被某个列表接口反复调用就是性能灾难的源头。有个实际例子某报表接口每次打开都要5秒用户基本不敢用。慢日志一查是一条count(*)拼了好几个表的统计SQL扫了上百万行。解决方案加了个合理索引直接降到300毫秒不到。4.2 索引设计没有银弹但有套路加了索引并非万事大吉很多慢查询其实“有索引也走得很烂”。排查SQL执行计划用EXPLAINEXPLAIN SELECT id, title, created_at FROM orders WHERE status 1 ORDER BY created_at DESC LIMIT 20;执行结果里几个关键列要会看列名含义重点关注type访问类型ALL是灾难ref/range/const都还好key实际用到的索引NULL说明没走索引rows预估扫描行数越大越危险Extra附加信息出现filesort/temporary要警惕设计索引有几个经验可以分享。联合索引要遵守最左前缀原则(status, created_at)能同时支持按status筛选和按created_at排序的场景。尽量用覆盖索引让查询的所有字段都在索引里省掉回表。排序字段最好跟索引匹配否则会产生Using filesort数据量大时性能很差。但也别走上另一个极端为每个查询建独立索引。索引本身占用空间还会拖慢写入。综合评判查询频率与写入频率保留收益最大的那几个就够了。4.3 干掉N1把逐条查询改成批量取数ORM确实提高了开发效率但也催生了大量N1查询——先查列表拿到N条记录再循环N次去查每条的关联数据。这是我在代码Review里见得最多的性能杀手。以常见的列表接口为例原先伪代码是这样$orders Order::where(status, 1)-get(); foreach ($orders as $order) { $user User::find($order-user_id); // 每次循环都是一次SQL $order-user_name $user-name; }改成批量取数$orders Order::where(status, 1)-get(); $userIds $orders-pluck(user_id)-all(); $users User::whereIn(id, $userIds)-get()-keyBy(id); foreach ($orders as $order) { $order-user_name $users[$order-user_id]-name ?? ; }同样是取800个用户信息原来要发800次查询现在一次搞定。如果ORM启用了关联预加载也要记得在查询时同时加载关联模型避免后续访问属性时触发惰性加载。另外做分页的时候要小心深分页。LIMIT 100000, 20这类写法MySQL还是要扫描前10万行再丢弃。优化思路是提前定位上一页的最大主键然后WHERE id 上一页最大id ORDER BY id LIMIT 20能省掉大量无效扫描。5. 缓存不是银弹但正确的缓存是真的香5.1 白捡的性能把OPcache配好多数PHP项目默认没开OPcache每来一次请求PHP都要把一堆脚本从磁盘读出来、做词法分析、编译成opcode再执行。这一步纯属重复劳动——代码又没变为什么每次都要重新编译在php.ini中开启opcache.enable1 opcache.memory_consumption128 opcache.interned_strings_buffer8 opcache.max_accelerated_files10000 opcache.validate_timestamps1 opcache.revalidate_freq60memory_consumption决定了能缓存多少编译产物128MB对绝大多数项目够用max_accelerated_files要大于项目实际PHP文件数可以执行find . -name *.php | wc -l统计一下再定validate_timestamps和revalidate_freq控制的是文件变更检测频率——开发环境开1秒方便调试生产环境如果发布流程比较规范可以设60秒甚至更高。有一个坑必须提醒如果OPcache内存设太小缓存会被频繁淘汰每次请求都重新编译反而比不开还慢。上线后可以用opcache_get_status()检查缓存命中率长期低于95%就要考虑调大内存。另外代码发布后如果线上环境没关闭校验并执行了opcache_reset就可能出现“代码改了但线上没变化”的幽灵问题这点也要纳入发布流程。5.2 Redis缓存该存的别缓存不该存的Redis是应用层缓存的重武器但用错了地方反而添乱。我的经验是下面这几类数据放在Redis里性价比极高热点列表首页推荐、分类导航、热门排行数据变化不频繁读多写少。计数器PV/UV、点赞数、库存余量配合原子操作。会话数据Session迁到Redis后多实例部署也不用担心Session不同步。重复计算结果复杂的聚合统计、报表数据。不适合缓存的是那些强一致要求极高的数据比如库存扣减的关键环节如果直接走Redis缓存就会面临缓存与数据库不一致的麻烦。宁可让这部分直查数据库也别为了一点性能给自己埋雷。缓存方案的设计上要特别注意三类典型问题缓存穿透查询一个肯定不存在的数据缓存没有数据库也没有每次请求都打到库。解决思路是空值也缓存或者用布隆过滤器拦截。缓存击穿某个热点key过期瞬间大量并发请求同时回源。用互斥锁保证只有一个请求去重建缓存其他请求等待即可。缓存雪崩大量key同时过期瞬时压力全部打向数据库。解决思路是过期时间加随机值错开过期时刻。这里给出一个典型的get-or-refresh代码骨架function getHotList(Redis $redis): array { $data $redis-get(hot:list); if ($data ! false) { return unserialize($data); } // 互斥锁防击穿 if ($redis-set(hot:list:lock, 1, [nx, ex 5])) { $data buildDataFromDb(); $redis-setex(hot:list, 300, serialize($data)); $redis-del(hot:list:lock); return $data; } // 没抢到锁等一会儿后读缓存 usleep(50000); return unserialize($redis-get(hot:list)); }实际开发里还可以用“逻辑过期”的方案缓存里保存一个过期时间戳发现逻辑过期后再去刷新期间旧数据继续服务能减少锁等待。5.3 HTTP层缓存让Nginx替你挡流量应用层缓存写好了还有更大的流量可以在HTTP层消化。如果一台Nginx反向代理PHP-FPM可以用FastCGI Cache把整个响应缓存住命中时根本不用经过PHP进程。在Nginx配置里启用最简单的用法fastcgi_cache_path /var/cache/nginx levels1:2 keys_zonephp_cache:10m inactive60m; fastcgi_cache_key $request_method$scheme$host$request_uri; fastcgi_cache_valid 200 60m;这样状态码为200的响应会被缓存60分钟。适合缓存的对象是通用信息类页面比如公开的文章详情、帮助文档、公告列表。需要注意如果接口跟登录用户相关缓存粒度就不能只按URI来得加入用户标识如果请求带Cookie且内容因人而异干脆跳过缓存。这种方案的收益非常直观——以前1000个请求打过来PHP-FPM要跑1000次有了缓存第一次回源后剩下999次直接由Nginx返回整个后端连日志都少写几条。6. 往下钻PHP进程模型与FPM调参背后的数学题6.1 先弄懂PHP-FPM的三种管理模式代码、SQL、缓存都优化到位了另一个容易被忽视的瓶颈是PHP-FPM本身的进程管理。先搞清楚它的三种进程管理模式。模式特点适用场景static启动时固定worker进程不变流量稳定、并发高dynamic按需在min和max之间伸缩大多数业务系统ondemand空闲即回收有请求才拉起流量极低、内存紧张static模式的优势是进程常驻、响应稳定缺点是流量低谷也在白白占内存。dynamic模式灵活但要小心参数设置不合理导致的频繁创建销毁进程。ondemand模式最省内存但请求进来时如果恰好需要新建进程首次请求会变慢。我的建议是大部分Web业务用dynamic负载落差大流量长期稳定偏高的static更可控。6.2 max_children不是拍脑袋拍出来的进程池配置里pm.max_children是最关键的参数它决定最多同时有多少个PHP进程在跑。但很多人的配置方式是“网上抄个数字”这非常危险——设太小高峰期排队设太大内存直接打爆。正确做法是先实测再计算用top或ps观察一段时间取单个PHP-FPM进程的内存峰值记为M。常见业务在40~80MB之间框架重的可能上百MB。统计同一台机器上其他服务的内存占用MySQL、Redis都是吃内存大户。总内存中扣除系统预留约0.5~1GB和其他服务占用再留出10%~20%余量得到PHP可用内存。计算公式大概是max_children ≈ (总内存 - 系统预留 - 其他服务占用) × 80% / 单个PHP进程内存举个例子一台2核4G的云主机同时跑了MySQL和Redis。系统预留约600MBMySQL约800MBRedis约200MB剩下约2.4GB。单个PHP进程平均按60MB算2400 × 80% ÷ 60 ≈ 32。所以max_children32是合理值设置成50以上反而危险。配套的dynamic参数可以这样给pm dynamic pm.max_children 32 pm.start_servers 8 pm.min_spare_servers 4 pm.max_spare_servers 12 pm.max_requests 5000 request_terminate_timeout 60启动进程数不要太高避免一开机就占用大量内存pm.max_requests的作用是让每个worker处理5000个请求后自动退出重建配合预防内存泄漏/碎片化。6.3 一个被忽略的进程级隐患内存悄悄爬升PHP-FPM的worker进程如果长期不重置内存占用会随着框架加载、类实例累积而缓慢上涨。时间一长进程内存从启动时的50MB涨到200MB以上整个服务器内存被逐渐吃光。处理方式就是上面的pm.max_requests——当worker处理到设定数量的请求后它会被回收重建内存回到初始水平。这个参数在长生命周期应用里几乎必设一般3000~10000之间看实际情况调节。另外还要注意不要在PHP-FPM进程里跑超长任务比如导入上万行Excel、循环发送大量邮件。这类任务会让worker长时间占用挤占正常请求的处理能力。正确做法是把耗时的任务丢到消息队列由独立消费进程慢慢处理。7. 一次完整的调优实战从3秒到300毫秒的拆解7.1 一个典型的“慢后台”问题描述用一个虚拟案例把前面讲的东西串起来。假设有一个内容管理后台其中一个列表页包含审核状态筛选、创建人姓名和统计计数。线上表现为点击页面要3秒多才能看到数据上午10点业务高峰时部分请求直接502。用户抱怨反复出现访问日志里大量超时。7.2 按顺序的四步定位链路我当时的排查顺序是这样的也建议你照这个顺序来浏览器访问页面跳过前端炒代码直接看TTFB2.8秒问题锁定在服务端。打开Nginx的upstream_response_time日志筛选出该列表接口显示平均耗时3.2秒P95接近4秒。打开PHP-FPM慢日志阈值设到2秒。几分钟后日志里出现了该接口的调用堆栈指向AuditController::index方法。在开发环境用Profiler跑一遍同样数据量的请求热点清晰可见一个循环内查询创建人昵称的函数被调了800次另有一条统计SQL没走索引单次耗时就超过600ms。排查结果的总结可以列成一张表排查步骤工具发现确认服务端问题浏览器TTFB / curlTTFB 2.8s确定具体接口Nginx timed log列表接口 p95≈4s定位代码位置PHP-FPM slowlogAuditController_list定位函数热点Profiler循环内SQL×800 全表count7.3 一处处改一步步验证接下来是修改。我坚持一个原则一次只改一处改完立刻压测验证再不进入下一项。因为如果一次性改好几处后面出了问题根本没法定位是哪个改动导致的回退。第一步给统计SQL加索引。把原本的全表扫描变成索引范围扫描这条查询从600ms降到10ms左右。第二步解决N1。不再在循环里查用户而是先取出所有user_id一次WHERE IN查询回来在内存里组装。这一步把800次查询压缩成1次接口耗时从2.4秒降到120ms。第三步把列表页的统计计数缓存到Redis设置5分钟过期并加随机过期偏差避免雪崩。高峰期的数据库压力明显下降不再出现偶发超时。第四步顺手检查了FPM参数发现max_children设置得远高于服务器能承受的数值随即将进程管理调成dynamicmax_children按内存实测改为32并设置pm.max_requests5000。高峰期502问题从此消失。最终效果接口响应稳定在30~60ms页面整体从3秒多降到300毫秒以内同样的压测条件下QPS翻了将近10倍。整个过程并没有改什么高深的算法全部是“先测量、再定位、精确打击”的常规操作。8. 性能调优不是终点建立长期防线8.1 把性能测试塞进日常发布流程很多团队只在出问题时才想起性能问题解决了就回到常态下次优化又从零开始。我的习惯是给关键接口建立性能基线用简单的压测工具定期跑一遍。ab是最容易上手的压测工具一条命令就能拿到基础数据ab -n 1000 -c 50 https://api.example.com/orders/list关注结果里的Requests per second和Time per request同时检查失败率。把关键接口的P95耗时写进监控看板每次发布前跑一次基准如果新版本比历史基线明显变差就该在发布前把问题拦下来而不是等到线上用户投诉。虽然wrk这类工具可以打出更丰富的压力模型但团队的落地成本才是关键。先用ab把习惯养起来比工具本身花哨与否重要得多。8.2 线上监控与告警守住底线上线后的监控指标至少要覆盖这几项PHP-FPM进程数、worker内存是否持续上涨。Nginx请求耗时、5xx/502状态码数量。MySQL慢查询条数、连接数、临时表数量。Redis内存占用、命中率、慢命令执行数。系统CPU/内存/磁盘I/O整体负载。告警阈值别设得太敏感否则会陷入告警疲劳真正出问题的时候反而没人看。告警的价值是发现问题不是增加噪音——先关注那些“一定会引起故障”的指标再逐步优化敏感度。8.3 代码Review时多问一句“性能呢”代码提交阶段就把性能问题消灭是成本最低的做法。我在做代码评审时会特别关注几个点循环里有没有查询数据库查询有没有用到索引大数据量列表是全量加载进内存还是分页同一个结果有没有重复计算而不是复用外部API调用能不能合并另外一个建议把每次优化记录下来形成一份优化清单。格式很简单记录“问题现象、定位手段、实际改动、优化前耗时、优化后耗时”这几个字段。这个清单既是团队的宝贵资产也是新成员上手排查的好教材。性能优化没有终点。业务在变、数据量在变、代码也在变今天调好的系统明天可能被一个新需求重新拉回瓶颈。但只要把“先定位再动手”的习惯培养起来把观测手段和压测流程沉淀成日常规范再复杂的性能问题都可以被一步步拆解掉。 
长河君 · 2026/10/16 3:53:41 · 阅读 1.2k PHP性能分析与调优：从定位瓶颈到实战优化的完整思路
接手过不少PHP项目也帮同行排查过线上故障我最大的感受是性能问题最忌讳“猜”。之前有个后台列表页从点击到出数据要3秒多高峰期直接卡死。我做的第一件事不是打开IDE撸代码而是把Nginx访问日志、PHP-FPM慢日志和MySQL慢查询日志三样东西摆在桌面上按顺序一点点往下剥。为什么要这么做因为“慢”可能发生在任何一个环节可能是代码写得烂也极有可能是数据库没走索引、FPM进程池配置不合理、缓存策略缺失甚至是前端资源加载拖了后腿。如果你一上来就埋头改函数运气好能挤出三五毫秒运气不好折腾一晚上毫无变化。这篇文章就是把我日常做PHP性能分析与调优的完整思路梳理一遍从定位瓶颈到实战优化每个环节都尽量给出能直接照着用的命令、配置和判断方法。适合正在为线上接口变慢发愁的开发者也适合刚接触性能优化、想建立系统排查思路的朋友。1. 先别急着改代码搞清楚慢的到底是哪一层1.1 用户说“慢”真的只是代码慢吗一次HTTP请求从用户浏览器到服务器再返回链路特别长浏览器发起请求、DNS解析、网络传输、Nginx接收、PHP-FPM处理、PHP框架运行、访问MySQL/Redis、外部API调用、模板渲染、响应回传、浏览器加载资源并渲染页面。你自己用浏览器访问一个页面感觉“卡”的体感时间是从点击到页面完整呈现的总时长。但这段总时长里PHP代码执行往往只占一小部分。我见过不少案例用户抱怨接口慢实际抓包一看是某个静态资源被外部引用拖到好几秒还有人折腾半天代码优化最后发现是Nginx配置里没开压缩光传输就占了大部分时间。所以第一步永远是先分清楚慢在哪一层。1.2 用手头的工具先把时间账算清楚浏览器开发者工具是最快的入手点打开Network面板刷新页面看瀑布图里每个请求的耗时分布。这里有个关键指标叫TTFBTime To First Byte指从发请求到收到响应第一个字节的时间。判断逻辑很简单TTFB高比如超过1秒说明服务端处理是重灾区问题大概率出在PHP、数据库或者Nginx配置上。TTFB低但整个页面加载慢说明重点在静态资源数量、资源体积、渲染阻塞这些前端因素上。网络本身慢比如请求在Waiting阶段耗时异常可能是网络链路、DNS解析或代理的问题。如果在服务器上我更习惯用curl直接看接口耗时分解。在执行环境里敲这样一条命令curl -o /dev/null -s -w DNS:%{time_namelookup} 连接:%{time_connect} TTFB:%{time_starttransfer} 总时间:%{time_total}\n https://api.example.com/orders/list返回结果里每一项都对应一个阶段DNS解析多久、建立连接多久、服务端处理到返回首个字节多久、整体多久。哪个环节异常一目了然。TTFB高就锁定服务端随后进入下一步排查。1.3 别把精力浪费在“看起来很慢”的代码上很多人一提起性能调优就喜欢抠字符串拼接用单引号还是双引号、foreach和for哪个快、函数调用能不能少一层。这些都属于“看起来很专业但收益极低”的改动。以PHP 7以上的性能一次普通的函数调用开销可以忽略不计真正吃掉大头的永远是外部依赖。根据我的经验真实业务里80%的性能问题集中在这几处循环内查询数据库一个列表页几百上千条记录每条都查一次累计下来就是秒级。SQL没走索引数据量一大就全表扫描。缺少缓存同一个热数据每次请求都重新计算、重新查库。框架/依赖初始化太重一个简单接口加载了几百个类。把这三类问题排查清楚收益比抠代码细节高几个数量级。所以整个调优流程应该是先测量、再定位、最后才动手改。2. 搭一套能说话的性能观测体系从日志到APM2.1 系统层面先看三张报表CPU、内存、磁盘I/O进入服务器后先别急着看代码用几条基础命令把系统状态摸一遍。第一条是top看整体负载和CPU占用重点观察php-fpm进程的数量和CPU占用率。如果worker进程数远小于请求并发CPU还有大量空闲说明瓶颈不在CPU而是进程不够、请求在排队。如果CPU跑满再配合其他工具确定是PHP代码计算密集还是SQL执行量太大。第二条是free -m看内存余量。PHP-FPM的worker进程是很吃内存的如果看到Swap使用量持续增长、系统频繁换页说明内存严重不足再好的代码也会被磁盘交换拖慢。第三条是iostat -x 1看磁盘I/O。很多团队忽略这个日志写得太猛、临时文件读写频繁、MySQL落在机械盘上都可能让请求变慢一个数量级。有一次我排查一个偶发抖动的问题最后定位是PHP错误日志每分钟写入几十兆磁盘I/O被打满改完日志级别立刻恢复。2.2 让Nginx和PHP-FPM把慢请求“吐”出来系统指标只能说明“资源吃紧”具体哪个接口慢得靠日志说话。Nginx默认的访问日志只记时间戳和URI把它扩展一下就能直接看到哪些页面耗时高。在Nginx的http块里自定义日志格式log_format timed $remote_addr [$time_local] $request $status request_time$request_time upstream_response_time$upstream_response_time; access_log /var/log/nginx/access_timed.log timed;这里request_time是Nginx处理请求的总时长upstream_response_time是后端PHP-FPM实际执行耗时。两者差距大说明耗时卡在Nginx与上游之间的排队或传输上基本一致说明是PHP本身执行慢。PHP-FPM慢日志则更直接——它能把“执行超过阈值”的请求堆栈原样打出来。修改PHP-FPM的pool配置slowlog /var/log/php-fpm-slow.log request_slowlog_timeout 2s2秒以上的请求会被记录到slowlog并且带上当时的PHP调用堆栈。这意味着一打开配置文件就能知道慢请求卡在哪个函数、哪一行。这个文件配合Nginx访问日志基本能锁定80%的线上慢接口。2.3 要不要上APM按团队规模和现状来定日志方案属于“事后知道慢”如果想看得更细、更实时可以引入APM应用性能监控工具。市面上的APM产品一般通过一个探针嵌入PHP进程把一次请求拆成框架初始化、业务代码、数据库查询、外部HTTP调用等若干片段并以火焰图或调用链的形式呈现。这对微服务、复杂调用链的排查效率提升非常明显。不过APM也不是非上不可。我的判断标准是如果项目接口数量少、调用链简单Nginx日志加PHP-FPM慢日志加Profiler足够如果项目微服务化、接口依赖多或者线上问题呈偶发性不是每次必现那上APM能省大量排查时间。选型上开源自建可以看基于采样模式实现的工具商业方案也有提供本地部署的版本。无论选哪个原则都一样探针本身的性能开销尽量低别为了监控让系统变慢。3. 用Profiler撕开代码的面具热点函数一目了然3.1 Profiler工作机制与怎么选日志能告诉你“这个请求慢”但不能直接告诉你“代码里哪个函数是元凶”。真要撕开函数级别的耗时分布得靠Profiler。Profiler大致分两种一种是采样式运行期间按固定频率采集当前正在执行的函数栈开销低适合线上环境短时间开启另一种是注入式对每个函数的进入和退出点做埋点统计数据精确但性能开销大适合开发环境。对PHP开发者来说最熟悉的注入式工具是Xdebug。本地开发环境开启profile模式的方法zend_extensionxdebug xdebug.modeprofile xdebug.output_dir/tmp/prof xdebug.profiler_output_namecachegrind.out.%t.%p配置完成后跑一次目标请求目录下会生成cachegrind格式的文件。这个文件可以用图形化工具打开也可以直接用命令行工具解析统计看到每个函数的调用次数和耗时。生产环境不建议全程开启Xdebug profile毕竟开销摆在那。我的做法是先在预发或本地复现开profiler拿到数据如果必须在线上排查用采样式工具短时间开启、拿完数据立即关掉。3.2 看懂一份Profiler报告先抓三个数字拿到Profiler报告后新手容易盯着图发呆。其实核心指标就三个调用次数一个函数被执行了多少次。如果次数上千甚至上万基本可以怀疑有循环内重复调用。自身耗时exclusive time函数体内部代码实际花掉的时间不包括调用其他函数的时间。累计耗时inclusive time本身耗时加上它内部所有调用的耗时体现该函数对整个请求的贡献。看报告时有一个很容易踩的误区某个函数的自身耗时只有几毫秒就以为不慢。但再看调用次数发现它在循环里被执行了800次累计就是秒级。有一个印象很深的案例——列表页慢得离谱Profiler显示一个SQL查询函数自身耗时只有3毫秒但调用次数被循环放大到800次累计2.4秒这才是真正的主犯。3.3 从报告到行动给热点排优先级面对一堆耗时不等的函数别眉毛胡子一把抓。我一般按三类处理自身耗时高的单个热点考虑优化算法本身检查是否在做无意义的重复计算、是否能提前break、是否能简化数据结构。调用次数高的函数考虑把循环内查询改成批量查询把重复计算结果缓存起来。累计耗时集中在下游调用的函数比如查询、外部API考虑能不能少调两次或者把逻辑下推到数据库里用一次SQL完成。第4章和第5章会展开这三类处理里最常碰到的两个战场数据库和缓存。4. 数据库往往是那只“房间里的大象”4.1 慢查询日志是最直接的证据如果Profiler显示大量时间花在SQL查询上下一步就是打开MySQL的慢查询日志。这是定位数据库瓶颈最直接的手段。修改MySQL配置一般写在my.cnf或my.inislow_query_log 1 slow_query_log_file /var/log/mysql-slow.log long_query_time 1 log_queries_not_using_indexes 1重启MySQL后执行时间超过1秒、或者没走索引的查询会被记进日志。日志积累一段时间后用自带工具归类统计mysqldumpslow -t 10 /var/log/mysql-slow.log它会把结构相似的SQL归并到一起并显示平均耗时、执行次数。按执行次数乘以单次耗时估算影响面优先处理“次数多又慢”的SQL——很多时候一条没索引的查询被某个列表接口反复调用就是性能灾难的源头。有个实际例子某报表接口每次打开都要5秒用户基本不敢用。慢日志一查是一条count(*)拼了好几个表的统计SQL扫了上百万行。解决方案加了个合理索引直接降到300毫秒不到。4.2 索引设计没有银弹但有套路加了索引并非万事大吉很多慢查询其实“有索引也走得很烂”。排查SQL执行计划用EXPLAINEXPLAIN SELECT id, title, created_at FROM orders WHERE status 1 ORDER BY created_at DESC LIMIT 20;执行结果里几个关键列要会看列名含义重点关注type访问类型ALL是灾难ref/range/const都还好key实际用到的索引NULL说明没走索引rows预估扫描行数越大越危险Extra附加信息出现filesort/temporary要警惕设计索引有几个经验可以分享。联合索引要遵守最左前缀原则(status, created_at)能同时支持按status筛选和按created_at排序的场景。尽量用覆盖索引让查询的所有字段都在索引里省掉回表。排序字段最好跟索引匹配否则会产生Using filesort数据量大时性能很差。但也别走上另一个极端为每个查询建独立索引。索引本身占用空间还会拖慢写入。综合评判查询频率与写入频率保留收益最大的那几个就够了。4.3 干掉N1把逐条查询改成批量取数ORM确实提高了开发效率但也催生了大量N1查询——先查列表拿到N条记录再循环N次去查每条的关联数据。这是我在代码Review里见得最多的性能杀手。以常见的列表接口为例原先伪代码是这样$orders Order::where(status, 1)-get(); foreach ($orders as $order) { $user User::find($order-user_id); // 每次循环都是一次SQL $order-user_name $user-name; }改成批量取数$orders Order::where(status, 1)-get(); $userIds $orders-pluck(user_id)-all(); $users User::whereIn(id, $userIds)-get()-keyBy(id); foreach ($orders as $order) { $order-user_name $users[$order-user_id]-name ?? ; }同样是取800个用户信息原来要发800次查询现在一次搞定。如果ORM启用了关联预加载也要记得在查询时同时加载关联模型避免后续访问属性时触发惰性加载。另外做分页的时候要小心深分页。LIMIT 100000, 20这类写法MySQL还是要扫描前10万行再丢弃。优化思路是提前定位上一页的最大主键然后WHERE id 上一页最大id ORDER BY id LIMIT 20能省掉大量无效扫描。5. 缓存不是银弹但正确的缓存是真的香5.1 白捡的性能把OPcache配好多数PHP项目默认没开OPcache每来一次请求PHP都要把一堆脚本从磁盘读出来、做词法分析、编译成opcode再执行。这一步纯属重复劳动——代码又没变为什么每次都要重新编译在php.ini中开启opcache.enable1 opcache.memory_consumption128 opcache.interned_strings_buffer8 opcache.max_accelerated_files10000 opcache.validate_timestamps1 opcache.revalidate_freq60memory_consumption决定了能缓存多少编译产物128MB对绝大多数项目够用max_accelerated_files要大于项目实际PHP文件数可以执行find . -name *.php | wc -l统计一下再定validate_timestamps和revalidate_freq控制的是文件变更检测频率——开发环境开1秒方便调试生产环境如果发布流程比较规范可以设60秒甚至更高。有一个坑必须提醒如果OPcache内存设太小缓存会被频繁淘汰每次请求都重新编译反而比不开还慢。上线后可以用opcache_get_status()检查缓存命中率长期低于95%就要考虑调大内存。另外代码发布后如果线上环境没关闭校验并执行了opcache_reset就可能出现“代码改了但线上没变化”的幽灵问题这点也要纳入发布流程。5.2 Redis缓存该存的别缓存不该存的Redis是应用层缓存的重武器但用错了地方反而添乱。我的经验是下面这几类数据放在Redis里性价比极高热点列表首页推荐、分类导航、热门排行数据变化不频繁读多写少。计数器PV/UV、点赞数、库存余量配合原子操作。会话数据Session迁到Redis后多实例部署也不用担心Session不同步。重复计算结果复杂的聚合统计、报表数据。不适合缓存的是那些强一致要求极高的数据比如库存扣减的关键环节如果直接走Redis缓存就会面临缓存与数据库不一致的麻烦。宁可让这部分直查数据库也别为了一点性能给自己埋雷。缓存方案的设计上要特别注意三类典型问题缓存穿透查询一个肯定不存在的数据缓存没有数据库也没有每次请求都打到库。解决思路是空值也缓存或者用布隆过滤器拦截。缓存击穿某个热点key过期瞬间大量并发请求同时回源。用互斥锁保证只有一个请求去重建缓存其他请求等待即可。缓存雪崩大量key同时过期瞬时压力全部打向数据库。解决思路是过期时间加随机值错开过期时刻。这里给出一个典型的get-or-refresh代码骨架function getHotList(Redis $redis): array { $data $redis-get(hot:list); if ($data ! false) { return unserialize($data); } // 互斥锁防击穿 if ($redis-set(hot:list:lock, 1, [nx, ex 5])) { $data buildDataFromDb(); $redis-setex(hot:list, 300, serialize($data)); $redis-del(hot:list:lock); return $data; } // 没抢到锁等一会儿后读缓存 usleep(50000); return unserialize($redis-get(hot:list)); }实际开发里还可以用“逻辑过期”的方案缓存里保存一个过期时间戳发现逻辑过期后再去刷新期间旧数据继续服务能减少锁等待。5.3 HTTP层缓存让Nginx替你挡流量应用层缓存写好了还有更大的流量可以在HTTP层消化。如果一台Nginx反向代理PHP-FPM可以用FastCGI Cache把整个响应缓存住命中时根本不用经过PHP进程。在Nginx配置里启用最简单的用法fastcgi_cache_path /var/cache/nginx levels1:2 keys_zonephp_cache:10m inactive60m; fastcgi_cache_key $request_method$scheme$host$request_uri; fastcgi_cache_valid 200 60m;这样状态码为200的响应会被缓存60分钟。适合缓存的对象是通用信息类页面比如公开的文章详情、帮助文档、公告列表。需要注意如果接口跟登录用户相关缓存粒度就不能只按URI来得加入用户标识如果请求带Cookie且内容因人而异干脆跳过缓存。这种方案的收益非常直观——以前1000个请求打过来PHP-FPM要跑1000次有了缓存第一次回源后剩下999次直接由Nginx返回整个后端连日志都少写几条。6. 往下钻PHP进程模型与FPM调参背后的数学题6.1 先弄懂PHP-FPM的三种管理模式代码、SQL、缓存都优化到位了另一个容易被忽视的瓶颈是PHP-FPM本身的进程管理。先搞清楚它的三种进程管理模式。模式特点适用场景static启动时固定worker进程不变流量稳定、并发高dynamic按需在min和max之间伸缩大多数业务系统ondemand空闲即回收有请求才拉起流量极低、内存紧张static模式的优势是进程常驻、响应稳定缺点是流量低谷也在白白占内存。dynamic模式灵活但要小心参数设置不合理导致的频繁创建销毁进程。ondemand模式最省内存但请求进来时如果恰好需要新建进程首次请求会变慢。我的建议是大部分Web业务用dynamic负载落差大流量长期稳定偏高的static更可控。6.2 max_children不是拍脑袋拍出来的进程池配置里pm.max_children是最关键的参数它决定最多同时有多少个PHP进程在跑。但很多人的配置方式是“网上抄个数字”这非常危险——设太小高峰期排队设太大内存直接打爆。正确做法是先实测再计算用top或ps观察一段时间取单个PHP-FPM进程的内存峰值记为M。常见业务在40~80MB之间框架重的可能上百MB。统计同一台机器上其他服务的内存占用MySQL、Redis都是吃内存大户。总内存中扣除系统预留约0.5~1GB和其他服务占用再留出10%~20%余量得到PHP可用内存。计算公式大概是max_children ≈ (总内存 - 系统预留 - 其他服务占用) × 80% / 单个PHP进程内存举个例子一台2核4G的云主机同时跑了MySQL和Redis。系统预留约600MBMySQL约800MBRedis约200MB剩下约2.4GB。单个PHP进程平均按60MB算2400 × 80% ÷ 60 ≈ 32。所以max_children32是合理值设置成50以上反而危险。配套的dynamic参数可以这样给pm dynamic pm.max_children 32 pm.start_servers 8 pm.min_spare_servers 4 pm.max_spare_servers 12 pm.max_requests 5000 request_terminate_timeout 60启动进程数不要太高避免一开机就占用大量内存pm.max_requests的作用是让每个worker处理5000个请求后自动退出重建配合预防内存泄漏/碎片化。6.3 一个被忽略的进程级隐患内存悄悄爬升PHP-FPM的worker进程如果长期不重置内存占用会随着框架加载、类实例累积而缓慢上涨。时间一长进程内存从启动时的50MB涨到200MB以上整个服务器内存被逐渐吃光。处理方式就是上面的pm.max_requests——当worker处理到设定数量的请求后它会被回收重建内存回到初始水平。这个参数在长生命周期应用里几乎必设一般3000~10000之间看实际情况调节。另外还要注意不要在PHP-FPM进程里跑超长任务比如导入上万行Excel、循环发送大量邮件。这类任务会让worker长时间占用挤占正常请求的处理能力。正确做法是把耗时的任务丢到消息队列由独立消费进程慢慢处理。7. 一次完整的调优实战从3秒到300毫秒的拆解7.1 一个典型的“慢后台”问题描述用一个虚拟案例把前面讲的东西串起来。假设有一个内容管理后台其中一个列表页包含审核状态筛选、创建人姓名和统计计数。线上表现为点击页面要3秒多才能看到数据上午10点业务高峰时部分请求直接502。用户抱怨反复出现访问日志里大量超时。7.2 按顺序的四步定位链路我当时的排查顺序是这样的也建议你照这个顺序来浏览器访问页面跳过前端炒代码直接看TTFB2.8秒问题锁定在服务端。打开Nginx的upstream_response_time日志筛选出该列表接口显示平均耗时3.2秒P95接近4秒。打开PHP-FPM慢日志阈值设到2秒。几分钟后日志里出现了该接口的调用堆栈指向AuditController::index方法。在开发环境用Profiler跑一遍同样数据量的请求热点清晰可见一个循环内查询创建人昵称的函数被调了800次另有一条统计SQL没走索引单次耗时就超过600ms。排查结果的总结可以列成一张表排查步骤工具发现确认服务端问题浏览器TTFB / curlTTFB 2.8s确定具体接口Nginx timed log列表接口 p95≈4s定位代码位置PHP-FPM slowlogAuditController_list定位函数热点Profiler循环内SQL×800 全表count7.3 一处处改一步步验证接下来是修改。我坚持一个原则一次只改一处改完立刻压测验证再不进入下一项。因为如果一次性改好几处后面出了问题根本没法定位是哪个改动导致的回退。第一步给统计SQL加索引。把原本的全表扫描变成索引范围扫描这条查询从600ms降到10ms左右。第二步解决N1。不再在循环里查用户而是先取出所有user_id一次WHERE IN查询回来在内存里组装。这一步把800次查询压缩成1次接口耗时从2.4秒降到120ms。第三步把列表页的统计计数缓存到Redis设置5分钟过期并加随机过期偏差避免雪崩。高峰期的数据库压力明显下降不再出现偶发超时。第四步顺手检查了FPM参数发现max_children设置得远高于服务器能承受的数值随即将进程管理调成dynamicmax_children按内存实测改为32并设置pm.max_requests5000。高峰期502问题从此消失。最终效果接口响应稳定在30~60ms页面整体从3秒多降到300毫秒以内同样的压测条件下QPS翻了将近10倍。整个过程并没有改什么高深的算法全部是“先测量、再定位、精确打击”的常规操作。8. 性能调优不是终点建立长期防线8.1 把性能测试塞进日常发布流程很多团队只在出问题时才想起性能问题解决了就回到常态下次优化又从零开始。我的习惯是给关键接口建立性能基线用简单的压测工具定期跑一遍。ab是最容易上手的压测工具一条命令就能拿到基础数据ab -n 1000 -c 50 https://api.example.com/orders/list关注结果里的Requests per second和Time per request同时检查失败率。把关键接口的P95耗时写进监控看板每次发布前跑一次基准如果新版本比历史基线明显变差就该在发布前把问题拦下来而不是等到线上用户投诉。虽然wrk这类工具可以打出更丰富的压力模型但团队的落地成本才是关键。先用ab把习惯养起来比工具本身花哨与否重要得多。8.2 线上监控与告警守住底线上线后的监控指标至少要覆盖这几项PHP-FPM进程数、worker内存是否持续上涨。Nginx请求耗时、5xx/502状态码数量。MySQL慢查询条数、连接数、临时表数量。Redis内存占用、命中率、慢命令执行数。系统CPU/内存/磁盘I/O整体负载。告警阈值别设得太敏感否则会陷入告警疲劳真正出问题的时候反而没人看。告警的价值是发现问题不是增加噪音——先关注那些“一定会引起故障”的指标再逐步优化敏感度。8.3 代码Review时多问一句“性能呢”代码提交阶段就把性能问题消灭是成本最低的做法。我在做代码评审时会特别关注几个点循环里有没有查询数据库查询有没有用到索引大数据量列表是全量加载进内存还是分页同一个结果有没有重复计算而不是复用外部API调用能不能合并另外一个建议把每次优化记录下来形成一份优化清单。格式很简单记录“问题现象、定位手段、实际改动、优化前耗时、优化后耗时”这几个字段。这个清单既是团队的宝贵资产也是新成员上手排查的好教材。性能优化没有终点。业务在变、数据量在变、代码也在变今天调好的系统明天可能被一个新需求重新拉回瓶颈。但只要把“先定位再动手”的习惯培养起来把观测手段和压测流程沉淀成日常规范再复杂的性能问题都可以被一步步拆解掉。