完整报告
典型页与最慢页并排对照。
典型页面（p50）与最慢的 5%（p95）均从顾客所在国家进行端到端测量，并排呈现同轮测试的服务器耗时、成功率和内存占用。
观看影片
2 vCPU 负载测试。
2 vCPU 下，40 位顾客同时访问：页面加载典型耗时 ≈0.4 s，服务端耗时 83–89 ms，99.97% 的访问无报错。
83–89 ms无页面缓存的单页服务端耗时
0.24–0.52 s20–30 位顾客同时访问时的典型页面
≈0.4 s40 位顾客同时访问时的典型页面
99.97%成功处理 7,714 个请求，无一报错
测试结果
小服务器，性能仍有富余。
应用、PostgreSQL、Redis 和后台任务进程全部共用同一台 2 vCPU 服务器，内存为 3.8 GB。
20–30 位顾客同时访问
典型页面耗时 0.24–0.52 s，最慢 5% 的页面耗时也在 1.5 s 以内，CPU 负载最高也只有一半。
40 位顾客同时访问
典型页面约 0.4 s，CPU 负载为 58–83%，仍留有余量。
每小时 43,000–50,000 个请求
在每秒 12–14 个请求下，这台小型服务器仍能从容应对繁忙的购物时段。
内存占用始终平稳
整轮测试期间，Web 容器内存保持在 225–262 MiB，系统仍有超过 2.4 GB 内存可用。
服务器端 83–89 ms
在顾客已登录且无页面缓存的条件下测得，这是服务器面临的最严苛场景。
搜索约 170 ms
同一台小型服务器上，商品搜索的服务端处理时间约为 170 ms。
测量方式
真实商店、真实访问路径、真实网络距离。
可信的数据来自熟悉的场景，因此我们完全按顾客实际访问的方式进行测量。
1
真实上线的商店
在 2 vCPU、3.8 GB 服务器上，真实服饰目录和结账流程全部运行在同一台机器上。
2
真实访问路径
70% 是新访客；每人打开 one to four 个页面，搜索、加购，两次点击之间阅读 5–15 seconds。
3
真实网络距离
k6 从顾客所在国家发起流量并开启 gzip，每个虚拟顾客都有独立会话。
4
计时口径透明
页面耗时包含网络和 TLS；服务器耗时不含页面缓存；采用启用 OPcache 的标准 PHP-FPM。
为何始终快
轻量设计，每次发布都经过测试。
提速无需升级服务器，靠的是应用的构建方式与验证流程。
轻量源于设计
先实测，再把系统做得更轻、更快。
每个页面都在服务器端渲染，脚本运行前即可阅读；所有访客通用的数据以缓存文件下发，模块仅在请求需要时启动。
- 商城页面从 501 KB 降至 78 KB
- 应用就绪耗时从 480–770 ms 降至 87–92 ms
- 访客页面按域名和语言分别缓存，重复访问可跳过数据库。
- 图片转为 WebP，并按各展示位匹配尺寸。
无需特殊运行时
普通托管环境也够快。
这些数据来自标准 PHP-FPM 与 OPcache 环境，未使用 Octane、Swoole、FrankenPHP 或 JIT。任何装有 Docker 的 Linux 服务器都能获得同样速度，也没有额外组件需要维护。
标准 PHP-FPMPHP 主机早已支持
OPcache 已调优开箱即适配大型应用
查询更精简关联数据提前批量加载，避免逐行读取
边缘节点缓存访客页面可接入 CDN
质量
每个版本都要过同一套关卡。
版本构建前会完成静态分析和超过 14,000 项自动化测试，避免新功能悄悄拖慢店铺或降低稳定性。
轻松扩容
顾客更多？扩容量，不必重写。
应用主要受 CPU 限制，且不保存本地状态，因此可随核心数扩展：先升配至 4 vCPU，再将数据库迁至独立服务器，最后在负载均衡器后增加应用服务器。
性能问题
关于速度，直说。
在我的服务器上也能这么快吗？
可以，前提是使用与测试环境相当、且靠近目标顾客的 2 vCPU 服务器。页面耗时包含网络传输，因此主机位置和服务器配置同样重要。
同时在线的顾客具体指什么？
指同一时段正在浏览的顾客；每人两次点击之间会停留 5–15 秒阅读。店铺同时有 40 人在线，每天可服务数千名访客。
流量增长后该怎么扩容？
先将服务器升配至 4 vCPU，再将数据库迁至独立服务器，最后在负载均衡器后增加应用服务器。每一步都无需更换软件，也无需迁移数据。
页面支持缓存吗？
支持。访客页面会按站点和语言分别缓存，访客再次访问时可直接读取缓存，无需访问数据库，也可在前方接入 CDN。本页展示的服务器耗时均在未启用页面缓存的情况下测得。
为什么不用 Octane 或 Swoole？
没必要。标准 PHP-FPM 能让托管环境更简单，性能表现也更可预期；应用本身已经足够轻量，无需特殊运行时也能跑出好速度。