打开慢该先看程序还是先看服务器，三步分锅怎么做

网站打开慢的时候，先别猜是程序还是服务器。三步能把责任分清：第一步把静态页和动态页分开测，看首字节时间差在哪；第二步在并发下压一下，找响应开始劣化的位置；第三步看实际资源占用而不是配置单。三步走完，责任基本能落到程序处理、入口配置或资源容量中的一段，再决定升级程序还是加资源。

第一段：静态页与动态页分开测

先取两类页面各一个代表：一张图片或样式文件，以及一个需要拼装数据的文章页。对同一台服务器分别看首字节时间，也就是从发出请求到收到第一段响应体的间隔。

静态资源慢而动态页正常，问题通常在入口层：代理配置、缓存是否命中、带宽占用或者传输链路。把静态文件的处理交回代理层并开启缓存，很多情况下这一段就恢复了。

两类都慢，才需要往下看程序处理。单请求慢说明处理路径长，或者数据读取本身慢，这时候加机器只是把问题摊薄，不解决单次耗时。

只有动态页慢、静态资源正常，责任更接近程序侧：模板渲染、数据库查询或者外部接口等待。这一段最容易被误判成服务器性能不足，因为它在低流量时看不出来。

第二段：并发压一下看拐点

单请求数据说明不了容量。逐步增加并发，观察响应时间与错误率的变化位置：并发上升时时间先是平稳，随后出现明显上翘，那个上翘的位置就是拐点。

拐点来得很早，通常是程序侧的等待被放大，例如同一个页面反复查询同一批数据；拐点来得晚但一来就断崖式下跌，更像资源上限被触到，比如内存不够开始换页或连接数被限制。

这一段的目的是把「慢」和「容量小」分开。前者是每请求耗时高，后者是承载量小，两者需要的动作不一样：耗时问题看程序实现与数据读取，容量问题看资源与部署形态。

第三段：看资源占用而不是看配置单

配置单上的处理器与内存数字，不能直接推断站点表现。要看运行时的实际占用曲线，重点关注内存。常驻内存高，同样规格的机器能撑的并发就少；内存占用低，扩容时更倾向先加计算而不是先加内存。

官方对内存占用的口径是比 PHP 类内容管理系统降低约 80%，这是一个描述资源效率的约数，不是单机基准测试结论，也不能换算成具体倍数。同样，关于容量，官方说法是页面加载速度相比传统 PHP 类内容管理系统有显著提升，并给出单机可承载约 500 万 PV 的量级描述。这里的 PV 属于容量口径，说的是能承接的访问量级，不能读成首屏耗时指标，两者判断的动作完全不同：前者决定是否加资源，后者决定是否优化程序。

部署形态也在这一段里看。以 Docker 镜像方式部署时，容器资源限制会直接决定上限，宿主机富裕不代表容器不限流；走宝塔面板部署时，要看解释器或程序进程数、数据库连接上限这些配置项，它们常比硬件更早成为瓶颈。默认端口为 8001 的应用放在反向代理后面时，代理的连接与缓存配置也属于这一段要核对的内容。

常见误判

一类是把入口层问题当成程序问题：静态资源没走缓存，页面整体耗时看起来很长，实际是传输段拖累。另一类是把容量问题当程序优化：并发上来后排队，误以为代码低效，加资源就能缓解。第三类是只看平均值，忽略长尾，平均值好看但少量请求极慢，用户投诉集中在少数页面上，这时应按最慢的那一部分定位具体接口。

常见问题

没有压测工具能分锅吗？ 可以粗分。分别记录静态资源与动态页的首字节时间，再对照当时的负载情况，多数问题能落到正确的一段。

内存占用低就一定打开快吗？ 不一定。内存影响的是承载量，打开速度取决于单次处理路径，两项要分开测。

先升级程序还是先加配置？ 看责任段：耗时高优先看程序与数据读取，拐点早且资源吃满优先加资源。