WordPress主机性能怎么看：分开测试缓存页面与动态请求

首页很快可能来自 CDN；后台保存、表单提交和购物车却仍要等待源站。两边都真实影响使用，只是不能互相代替。本篇适合已有候选套餐或正在排查性能的人；托管责任、预算与恢复能力，可以先看WordPress 主机选择。这里不提供未经实测的品牌排名。

先挑选能代表业务的测试任务

不要用空白 WordPress 演示站代表自己的业务站。至少选一张真实布局的公开文章或产品页，以及一项经过确认的动态操作。图库多的站点，还可以加入一项常见后台维护任务，单独观察资源占用。

样本	用来回答什么	结果不能代替什么
已命中缓存的公开首页或文章	访客取得公开内容的分发体验	未缓存时的 PHP 和数据库处理能力
经确认不走整页缓存的业务请求	应用处理与动态等待	所有页面的真实访客体验
后台保存、导入或生成缩略图等实际任务	日常维护是否稳定，后台任务是否挤占资源	全站可承受的固定在线人数

询盘站可以用保存测试草稿和提交测试表单；交易站在隔离环境里用购物车和测试结算。选本站实际使用的任务，不为测试临时装一堆插件。

动态也要有证据。登录、Cookie、参数和主机规则都会影响缓存状态；给 URL 随便加一个随机参数，并不能保证绕过所有缓存。让主机说明可用的检查方法，或在隔离副本里明确控制对应缓存。缓存冷启动与热命中也分开记录，不能把刚清缓存的一次生成，与另一家已预热的结果直接比较。

公开内容站可以重视缓存后的访问，但仍需要确认编辑与发布正常。会员、交易和复杂查询站，则必须给动态结果足够权重。

套餐参数要读成实际限制

CPU、内存与 PHP 并发都重要，但它们不是“每月支持多少访客”的直接换算表。访客停留在页面阅读时不一定持续占用 PHP，请求则可能因数据库或外部接口长时间没有结束。

在 PHP-FPM 环境中，pm.max_children 控制相应进程池能够同时服务的请求数，见 PHP-FPM 配置说明。它不是同时在线人数，也不是每秒固定能完成多少次询盘。其他主机栈可能使用不同机制，应让供应商说明自己的限制。

如果一个请求本来就很慢，提高同时处理数量可能让更多请求一起占用内存，却没有缩短单次执行。反过来，单次执行很快、忙时只是等待空闲进程，增加合适资源才可能更直接。判断之前先把两种情况分开。

询问套餐时，要求得到这些具体答案：

• CPU 是共享额度还是可持续使用的资源，达到限制后会限速、排队还是报错？
• 整站或容器内存与单个 PHP 请求的内存上限分别是什么？
• 动态并发、数据库连接和存储 I/O 是否有限制，哪些能看到使用记录？
• 备份、导入、计划任务与访客请求是否共用同一资源范围？
• 发生慢请求时，能否得到对应时间的错误、队列和资源数据？

不要把单次 PHP 内存上限当作整台机器可用内存，也不要把硬盘容量增加当作动态处理能力增加。软件版本先满足当前 WordPress 环境要求并兼容插件；“能安装”仍只是前提。

比较两家主机，先固定站点和条件

准备接近实际用途的站点副本，主题、插件版本、图片、页面与数据库规模尽量相同。客户资料要脱敏，邮件、支付和外部自动化在测试环境中隔离，避免重复提交产生真实副作用。

有两种比较方式，要分开记录：

比较交付体验。 两家都使用各自推荐且准备实际采用的配置，包括缓存和 CDN。结果回答“购买并这样使用后，关键任务是否满足要求”。

定位源站差异。 某组结果异常时，再控制缓存和网络路径，查看源站处理。结果帮助解释原因，而不是拿一边的边缘命中与另一边的源站生成比较 CPU。

固定测试位置。前台使用目标访客附近的地区；后台维护还要看自己日常工作的网络。两家所测机房、CDN、认证和安全规则不同，都要注明。测试副本资源是否等同正式套餐，也要向供应商确认。

留一份最小记录即可开始：

记录项	示例写法
页面或操作	同一产品详情页；保存同一份测试草稿
请求状态	匿名公开页，已确认命中；测试账户，动态请求
环境	套餐名称、机房、PHP 版本、缓存与 CDN 配置
测试条件	地区、时间、网络模拟、是否首次连接
观察结果	耗时、波动、错误与业务是否完成
同期资源	CPU、内存、队列、慢查询或主机提供的限制记录

持续复用这份记录，不必每轮换测法。供应商特制演示站可以作为参考，但没有相同内容与条件时，不宜当成自己的性能保证。

低负载先测通，再看等待发生在哪里

从一个访客的正常任务开始。浏览器 Network 的主文档 Timing 可以帮助看连接和等待，但 TTFB 不等于纯 PHP 执行时间；DNS、连接、跳转与网络都可能参与其中，见 TTFB 说明。不同工具显示的服务器响应项也可能只包含部分阶段，不要把名称相近的数据直接混算。

连续测几次，保留结果与波动，别只挑最快的一次。第一次请求可能涉及连接建立、缓存生成或应用初始化；后续请求更快，必须知道复用的是哪一层。必要时请供应商提供受控的源站或服务端计时，而不是仅靠浏览器总耗时猜数据库。

如果 HTML 很快返回，而首屏图片或布局迟迟不出现，主机未必是当前最大的瓶颈。反之，HTML 请求明显等待，再结合缓存状态、地区和服务器计时继续查。相关分层方法可参考 TTFB 优化，前台资源问题则继续看WordPress 速度优化。

还要检查结果是否真的正确。一次表单请求返回 200，却在页面里显示验证失败，不能算成功提交；后台保存请求结束，也要确认内容已经保存。技术状态与业务结果都需要通过，否则“更快”的错误页面没有比较价值。

忙时要同时看延迟、错误和排队

低负载正常后，先观察真实忙时。有必要做并发测试时，只在主机允许的隔离环境中安排，提前明确任务、速率、停止条件与副作用。不要向无授权的第三方演示站加压，也不要反复制造真实订单或邮件。

测试应接近业务：读公开文章和提交动态操作的比例不同，得到的容量结论也不同。每个虚拟用户连续无停顿地发请求，与真实人读完一段再点击，并不是同一负载。请求数、虚拟用户数和在线人数不能直接划等号。

结果至少看持续时间分布、错误率和业务检查。P50 表示中间水平，P95 可帮助观察较慢一侧的体验；样本很少时，百分位会不稳定。平均很快但少数操作持续超时，也不能算稳定。Grafana 的 k6 指标文档说明了不同指标的用途。

通过标准按业务确定。例如在测试前约定重要操作允许的等待、错误和业务结果，而不是照抄工具示例中的毫秒数。自动阈值可以标记失败或按配置停止测试，参见 k6 阈值说明。本文没有对任何主机实施压力测试，供应商若交付报告，也应同时给出脚本逻辑与条件。

出现持续排队或错误时停止增加负载，保留发生时间和 URL，让维护者对照资源。PHP-FPM 环境可看 listen queue、活动进程和 max children reached 等，但历史累计值非零不代表当前必然需要升级。要看异常时段是否增加、是否同时排队以及请求在做什么。字段含义见 PHP-FPM 状态页；状态数据由受控面板或运维提供，不应公开给访客。

把现象转成升级、优化或换地区的决定

观察到的差异	应先查的证据	有依据的下一步
缓存页快，单次动态操作已慢	慢查询、插件执行、外部API等待	优先修应用；扩进程池未必缩短单请求
单次动态正常，集中访问排队	异常同一时段的队列、进程及其他资源限制	评估增加对应资源；询问数据库与存储是否仍限流
源站附近正常，客户地区慢	两地区相同页面、缓存状态和访问路径	比较机房、线路或分发方案，不能只换同地区套餐
HTML快，浏览器仍卡顿	图片、样式下载和脚本执行	优先修前端；不把它记为主机处理慢
只在备份、导入或批处理时慢	任务开始结束时间与资源竞争	调整批量规模或运行时段，再判断长期资源需求

单次动态执行问题可沿WordPress性能说明继续定位；地区差异则结合WordPress CDN检查。升级方案应写清增加的是CPU、内存、进程额度还是磁盘空间，它必须对应表中已经证实的限制。

多种问题也可能同时存在。把已证实的因素逐项处理，再用同样条件复测，避免一次更换主机、主题、缓存和图片之后无法知道哪里真正改善。

购买或升级前，保留能复核的结论

把最重要的任务放在前面比较。文章站需要公开访问稳定、发布更新及时、后台编辑够用；交易或会员站还要确认动态任务忙时没有明显排队和错误。不要用一个总分覆盖两种业务。

保存具体套餐名称、资源政策、测试条件和供应商对异常的解释。若测试权限有限，就把已知与未知分开写：公开演示页表现正常，不代表已验证自己的表单、数据库规模或忙时容量。

最终结论可以很具体：“这份站点副本在这些地区、缓存与任务条件下满足要求；如果未来动态队列达到哪种情况，再评估增加对应资源。”这样的记录，后续升级时能继续用。单纯给某个品牌贴上永久的“最快”标签，无法替代自己网站的实际需求。