美国VPS能扛多少并发

一、并发和 QPS 到底有什么区别

先把概念理清楚，后面所有计算都基于这个区分。

并发（Concurrency） 是同一时刻正在处理的请求数。QPS（每秒查询数） 是单位时间内完成的请求数。两者的关系是：并发数 = QPS × 平均响应时间（秒）。

举个例子：QPS 是 100，平均响应时间 0.2 秒，那么并发数是 100 × 0.2 = 20。也就是说 100 QPS 的业务，服务器上同时有 20 个请求在处理中。

这个换算关系是整篇文章的核心工具。因为 VPS 厂商标的是硬件规格（核数、内存、带宽），而你关心的业务指标是 QPS 或同时在线人数，所以必须把两者换算到同一个语言。

同时在线人数和并发也不是一回事。 一个人打开一个页面，会产生 HTML 请求、若干 CSS、JS、图片请求，然后可能每隔 30 秒轮询一次接口。假设一个页面产生 15 个请求、平均停留 3 分钟，那么：

单用户产生的请求数 = 15 + (180 秒 / 30 秒) × 1 = 21 个请求
并发数 = 在线人数 × 21 ÷ 180 秒 = 在线人数 × 0.117

1000 人同时在线，对应约 117 的并发。 记住这个系数，它比拍脑袋估「1000 人要多少并发」靠谱得多。

查 spinservers 在售套餐与库存

为什么商家的「支持 XX 并发」不可信。 商家说「支持 5000 并发」时，指的通常是某个特定压测脚本跑出来的连接数上限——通常是纯静态页或者一个返回空响应的小脚本。而你的真实业务是跑 PHP、查数据库、渲染模板、读文件。三者的资源消耗差着几个数量级。

二、并发是被什么东西卡住的

一条请求要依次通过四道关卡，任何一道卡住，其余三道再强也没用。

第一关：CPU。 每个请求都要执行代码。PHP 一次请求的 CPU 消耗大概 10 到 50 毫秒（视代码复杂度），一台 4 核机器理论上每秒能处理 4 ÷ 0.03 ≈ 133 个纯 CPU 请求。实际打七折，算 90 QPS。

第二关：内存。 每个 PHP-FPM 进程占 30 到 60 MB 内存。1 GB 内存的机器扣掉系统和缓冲，能给 PHP 的大约 600 MB，也就 10 到 20 个进程。内存往往比 CPU 更早成为瓶颈。

第三关：PHP-FPM 进程数。 这是最直接的一道闸门。pm.max_children 设成 10，那并发上限就是 10——第 11 个请求进不来，排在 listen backlog 队列里。这是硬限制，不管机器有多少核。

第四关：数据库连接数。 每个 PHP 进程持有一个数据库连接。MySQL 的 max_connections 默认是 151，PHP-FPM 20 个进程加其他客户端还好，但如果你把进程数调到 100，数据库连接就排队了。典型症状是「CPU 不高但请求超时」。

第五关：带宽。 一个页面 2 MB，10000 并发如果都是新访客要下全量资源，瞬时带宽需求就是 20 GB/s。这在任何单台 VPS 上都不可能达到。但实际上并发用户共享 CDN 缓存后，这个数会小一到两个数量级。

关卡	典型限制	怎么确认是它卡住了
CPU	核数 × 1000 ÷ 单请求 CPU 毫秒	top 里 %CPU 长期接近 100
内存	(总内存 1G 系统占用) ÷ 每进程 60MB	free -m 里 available 接近 0
PHP-FPM 进程数	pm.max_children	`ps aux \	grep php-fpm \	wc -l`
数据库连接	max_connections	SHOW STATUS LIKE 'Threads_connected'
带宽	带宽 Mbps ÷ 页面大小 × 8	压测时看网卡流量是否打满

zenlayer 官网机型与实时报价

排查顺序建议：先看 PHP-FPM 进程数是不是顶到了 pm.max_children，再看内存，最后才看 CPU。因为进程数和内存这两道门经常先卡住，而且改起来最便宜。

三、怎么算出自己机器的并发上限

用商品库里的真实机型算一遍。

先算内存这一关。 公式是：可用进程数 = (物理内存 1 GB 系统占用) ÷ 60 MB。留 1 GB 是给系统、Nginx、数据库、文件缓存用的。

以 RosCloud-01 为例：2 核、1 GB 内存、20 GB 硬盘、500 Mbps 带宽、每月 1024 GB 流量，19.99 美元每月。

(1024  1024) ÷ 60 ≈ 0

结果接近 0 意味着：这台机器跑纯 PHP 动态站几乎没有余量。实际做法是只留 3 到 5 个 PHP 进程，其余内存全给数据库和文件缓存。这个配置适合的场景是「静态页 + 很轻的动态接口」，或者「跑代理、跑脚本」这类不依赖 PHP 的用途。

以 RosCloud-03 为例：4 核、4 GB 内存、80 GB 硬盘、500 Mbps 带宽、每月 3072 GB 流量，39.99 美元每月。

(4096  1024) ÷ 60 ≈ 51 个进程

但 CPU 那一关只允许 4 核 ÷ 30 毫秒 ≈ 133 QPS。所以 pm.max_children 设 30 左右比较合理——再高就是浪费内存，因为 CPU 根本喂不饱。

以 LAX-MICRO 为例：4 核、4 GB 内存、80 GB 硬盘、4000 Mbps 带宽、每月 10000 GB 流量，年付 400 美元折合每月 33.33 美元。

内存关：约 51 个进程
CPU 关：约 133 QPS

结论和 RosCloud-03 基本一致，但带宽高得多（4000 对 500 Mbps），这决定了它的静态资源分发能力。

再算一个对照：LAX-STARTER，2 核、2 GB 内存、40 GB 硬盘、2000 Mbps 带宽、每月 5000 GB 流量，年付 200 美元折合每月 16.67 美元。

内存关：(2048  1024) ÷ 60 ≈ 17 个进程
CPU 关：2 ÷ 0.03 ≈ 66 QPS

估算表汇总（假设单请求 CPU 30 毫秒、平均响应 200 毫秒）：

机型	配置	价格	PHP 并发上限	估算 QPS
RosCloud-01	2 核 1G 20G 盘 500M 1024G 流量	19.99 美元/月	3 到 5	20 到 30
RosCloud-02	3 核 2G 40G 盘 500M 2048G 流量	29.99 美元/月	10 到 15	50 到 70
RosCloud-03	4 核 4G 80G 盘 500M 3072G 流量	39.99 美元/月	25 到 30	90 到 120
LAX-STARTER	2 核 2G 40G 盘 2000M 5000G 流量	16.67 美元/月（年付 200）	10 到 15	50 到 70
LAX-MICRO	4 核 4G 80G 盘 4000M 10000G 流量	33.33 美元/月（年付 400）	25 到 30	90 到 120
LAX-MEDIUM	8 核 8G 160G 盘 10000M 20000G 流量	66.67 美元/月（年付 800）	55 到 65	220 到 260

查 goodlyclouds 在售套餐与库存

这张表的用法：找到你的机型，看 PHP 并发上限那一列，乘以 60（每分钟 60 秒）得到每分钟能处理的请求数，再按第二节的「单用户请求数」换算成能支撑多少人。

举例：LAX-MICRO，PHP 并发 25，单用户每分钟产生 21 个请求（按前面算的 3 分钟停留、15 个资源算），那 25 × 60 ÷ 21 ≈ 71 个并发用户，按第二节的系数 0.117 反推约 600 人同时在线。

这些数字是估算，不是保证值。 它们假设代码是「正常写法」——没有 N+1 查询、没有未优化的循环。代码质量差十倍，并发就掉十倍。

四、PHP-FPM 怎么配：并发调优的核心

PHP-FPM 的配置是并发能力的第一道人工阀门。

; /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic

; 关键参数：这个值就是 PHP 的硬并发上限
pm.max_children = 25

; 启动时的进程数
pm.start_servers = 3

; 空闲进程数的下限和上限
pm.min_spare_servers = 3
pm.max_spare_servers = 8

; 每个进程处理多少请求后重启（回收内存泄漏）
pm.max_requests = 500

; 进程空闲多久后退出
pm.process_idle_timeout = 10s

怎么定 pm.max_children。 三条约束取最小值：

第一条，内存约束：(总内存 1 GB) ÷ 60 MB。

第二条，数据库约束：max_connections ÷ 1.2（留 20% 余量给其他客户端）。

第三条，CPU 约束：核数 × 1000 ÷ 单请求 CPU 毫秒 × 0.8。

举例：4 核 4 GB 机器，MySQL max_connections 是 151，单请求 CPU 30 毫秒。

内存约束：(4096  1024) ÷ 60 = 51
数据库约束：151 ÷ 1.2 = 125
CPU 约束：4 × 1000 ÷ 30 × 0.8 = 106
取最小值 → pm.max_children = 51，但实践中取 30 左右

为什么不取满 51？因为 CPU 约束 106 意味着 CPU 最多支撑 106 QPS，而 51 个进程在 QPS 达到 106 时每个进程才占用约 2 QPS，空闲的进程纯粹浪费内存。留一定余量给内存碎片和突发。

pm = ondemand 和 pm = static 什么时候用。 ondemand 适合流量波动大的场景，进程用完就起、用完就杀，省内存但有启动延迟（首次请求会慢几十毫秒）。static 适合流量稳定的场景，启动就固定进程数，响应延迟最低，但内存占用恒定。个人站和 WordPress 站建议 ondemand，配置低延迟的 API 服务建议 static。

pm.max_requests 一定要设。 PHP 有内存泄漏，进程跑久了会涨到几百 MB。不设这个参数，你的机器会在运行几天后因为内存耗尽开始 OOM Killer 杀进程，表现为「运行一段时间后突然开始 502」。设成 500 是常见的折中值。

内存泄漏的排查方法。 观察每个 PHP 进程的常驻内存是否随时间增长：

# 列出所有 php-fpm 进程的 RSS（常驻内存），按大小排序
ps -eo pid,etimes,rss,cmd --sort=-rss | grep "[p]hp-fpm: pool www" | head -20

# etimes 是进程已运行的秒数，rss 是 KB
# 找一个 etimes 很大（跑了很久）且 rss 也不小的进程，就是泄漏的那一个

如果同一批进程里，跑了 5 小时的 RSS 是 120 MB、跑了 1 小时的是 60 MB，那泄漏速率约是每小时 12 MB。设 pm.max_requests = 500 后，进程会被定期回收，泄漏就被限制了。

改完配置的验证方法。

# 改完先测试配置语法
php-fpm8.2 -t

# 重载（不重启，不中断正在处理的请求）
systemctl reload php8.2-fpm

# 看实际起多少个进程
ps aux | grep -c "[p]hp-fpm: pool www"

关于 FPM 的连接方式。 用 Unix socket 而不是 TCP 端口（127.0.0.1:9000）会更省一点开销：省掉 TCP 的三次握手，也避免内核的 TCP 缓冲区占用。在 php-fpm.conf 里：

listen = /run/php/php8.2-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Nginx 那边对应改成：

fastcgi_pass unix:/run/php/php8.2-fpm.sock;

这个改动的收益在小流量时几乎看不出来，在高并发时能省出几个百分点的 CPU。 属于做了没坏处的事。

sakuraclouds 官网机型与实时报价

另一个容易忽略的点：Nginx 的 worker_connections 不用改太大。 常见的默认配置是 512 或 1024，但你的瓶颈在 PHP 那一侧，把 Nginx 的连接数调成 65535 并不会让 PHP 的并发变大。真正需要 Nginx 扛大连接的场景是 WebSocket 或大量静态文件直出。

五、数据库连接数怎么配才不互相打架

数据库连接是最常见的隐形瓶颈。

先看现状。

-- 当前连接数
SHOW STATUS LIKE 'Threads_connected';

-- 最大连接数
SHOW VARIABLES LIKE 'max_connections';

-- 各连接在干什么
SELECT id, user, host, db, command, time, state, LEFT(info, 100) AS q
FROM information_schema.processlist ORDER BY time DESC;

-- 看连接有没有堆积
SHOW STATUS LIKE 'Threads_created';

连接数超限时的报错长这样：

SQLSTATE[HY000] [1040] Too many connections

三个必须做的配置。

第一，给 PHP 配连接池或持久连接。PDO 的持久连接能大幅降低建立连接的开销：

// 持久连接（注意：会导致空闲连接不释放，max_connections 要留余量）
$pdo = new PDO($dsn, $user, $pass, [
    PDO::ATTR_PERSISTENT => true,
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
]);

第二，给应用层设连接上限。如果用连接池（像 Swoole、Workerman、Runtime 这类），池子大小应该等于或略小于 pm.max_children，而不是每个进程各开一个池。

第三，调整 MySQL 的 max_connections 并同步改内存配置。max_connections 上调不是免费的，每个连接要占内存（基础约 1 MB，加上排序缓冲等），所以：

[mysqld]
max_connections = 200
# 每连接的额外内存开销
sort_buffer_size = 1M
join_buffer_size = 1M

200 个连接 × 2 MB 额外缓冲 = 400 MB。4 GB 机器这样配没问题，1 GB 机器配 200 就是灾难。 所以 1 GB 机器的 max_connections 建议保持在默认的 151 以下，靠 PHP 侧限制并发而不是靠数据库侧放宽。

查看 serverfield 当前月价与库存

连接数与并发的换算：每个 PHP 进程同时只有一个数据库连接（除非你的代码里嵌套查询）。所以并发上限 = min(PHP 进程数, 数据库可用连接数)。如果数据库 max_connections 是 151，而 PHP 进程数是 25，数据库根本不是瓶颈，你可以放心地把 PHP 进程数往上加。

六、压测：怎么量出真实的并发能力

不压测就不知道自己的机器能扛多少。这一节给出可以直接用的命令。

工具选择：wrk 优于 ab。 wrk 是多线程的，ab 是单线程的，压同一台机器时 ab 自己就成瓶颈了。

# 安装
apt install -y wrk

# 基本用法：10 个连接，跑 30 秒，2 个线程
wrk -t2 -c10 -d30s https://your-site.com/

# 带请求的 POST 压测
wrk -t2 -c50 -d60s -H "Content-Type: application/json" \
    --post '{"action":"getList","page":1}' https://your-site.com/api

# 看延迟分布（这个比平均延迟有用得多）
wrk -t2 -c50 -d60s --latency https://your-site.com/

输出解读。 一次典型输出：

Running 1m test @ https://your-site.com
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.23s     0.45s    2.10s   89.00%
    Req/Sec    48.2      8.1     62.0    72.00%
  Latency Distribution
     50%    1.10s
     75%    1.35s
     90%    1.65s
     99%    2.05s
  28926 requests in 1.00m, 12.35MB read
Requests/sec:   482.3

要看的不是平均值，是分位数和错误率。 50% 是 P50，90% 是 P90，99% 是 P99。判断标准：

指标	通过线	说明
错误率	0%	有 502、504 就是没扛住
P95 延迟	小于 2 秒	超过说明有请求在排队
P99 延迟	小于 5 秒	长尾说明有资源瓶颈
压测中 CPU	70% 到 85%	长期 100% 说明已到上限
压测中内存	无持续增长	增长说明有泄漏

查看 干杯cloud 当前月价与库存

渐进加压找到拐点。 这是找到真实上限的正确方法：

for c in 5 10 20 40 60 80 100; do
  echo "=== 并发 $c ==="
  wrk -t2 -c$c -d20s --latency https://your-site.com/ 2>&1 | grep -E "Latency|Req/Sec|requests in"
  sleep 5
done

在并发数翻倍时，如果 QPS 没有相应增长，就是找到拐点了。 比如 40 并发时 QPS 是 400，80 并发时还是 400（延迟翻倍），那 40 就是这台机器在当前代码下的实际上限。

压测的三个坑。

第一，压测机本身要和被测机隔离。用同一台机器压自己，测出来的瓶颈是压测进程。

第二，压测的是缓存命中还是数据库读。要测真实容量，先清缓存：

# MySQL 8.0 清查询缓存已废弃，改测真实场景
# 清 Redis / Memcached 缓存
redis-cli FLUSHALL
# 或
echo 3 > /proc/sys/vm/drop_caches   # 清页缓存（需要 root）

第三，压测会产生大量流量和数据库写入。用商品库里流量配额小的机型时要注意：LAX-STARTER 每月 5000 GB 流量，一次带 1000 并发的 30 秒压测可能就打掉几个 GB。压测流量会从配额里扣。

压测前要做的四件事，否则测出来的数据没有参考价值。

第一，关掉所有缓存，确保测的是应用本身的处理能力。缓存命中率和冷启动是完全不同的两个世界。

第二，把数据库恢复到接近生产的数据量。 一张只有 100 行的表和一个有 100 万行的表，查询耗时可能差 100 倍。在空表上测出的并发数，在生产环境会瞬间崩掉。

第三，确认 PHP 进程数已经按生产配置设好。 压测机上的 pm.max_children 要是 100 而生产是 25，测出来的数没有意义。

第四，用和生产相同的 PHP 版本和配置。 开了 OPcache 和没开，QPS 能差 30% 到 50%。

压测脚本的常见错误。

最常见的是压测结果「看起来很漂亮但线上照样慢」。三个典型原因：

原因是压测脚本只请求了一个 URL。首页是缓存命中最高的页面，压它等于测了个寂寞。要压最重的那个接口——搜索、详情页、下单。

原因是压测期间没有模拟真实用户的请求分布。真实用户里 80% 是浏览列表、15% 是看详情、5% 是下单。如果只压列表页，数据库的热点是另一个表。

原因是压测机到被测机之间的网络比真实用户更短。你在自己机房压测，RTT 可能只有 1 毫秒，而真实用户到美西是 200 毫秒。跨洋的 200 毫秒 RTT 会让并发需求大幅上升，因为每个请求占用的连接时间更长。

这一点值得展开算一下。 假设应用处理时间是 50 毫秒，用户 RTT 是 200 毫秒，那么单请求在服务器侧占用连接的时间是 50 毫秒。100 QPS 需要 5 个并发。但如果服务器在上海而用户也在上海，RTT 是 1 毫秒，同样 100 QPS 只需要 5 个并发——看起来一样，但真实用户体验差 200 毫秒。

换个角度：同样是 25 并发，RTT 200 毫秒的机器能跑 25 ÷ 0.05 = 500 QPS；RTT 1 毫秒但服务器处理要 200 毫秒的机器只能跑 25 ÷ 0.2 = 125 QPS。并发数相同，吞吐差 4 倍。

所以压测时最好模拟真实 RTT。 可以在压测机上加延迟：

# 用 tc 给压测流量加 200 毫秒延迟，模拟跨洋 RTT
tc qdisc add dev lo root netem delay 100ms
# 测完记得删掉
tc qdisc del dev lo root

七、静态页、动态页和 API 的并发差异有多大

同样一台机器，跑不同的东西，并发能力差几个数量级。这是估算时最容易搞错的地方。

场景	单请求资源消耗	4 核 4 GB 机器的并发估计
Nginx 直接返回静态文件	几乎只占 IO，不占 CPU	1000 以上
Nginx 返回缓存命中的动态页	少量 PHP 启动开销	300 到 500
PHP 动态页（查库 + 渲染模板）	30 毫秒 CPU + 1 次查询	25 到 30
PHP 动态页 + 无索引慢查询	200 毫秒以上 CPU + 锁等待	5 到 10
API 接口（纯 JSON，无模板）	10 毫秒 CPU	80 到 120
长连接 WebSocket	每个连接常驻内存	数百到数千

查 cubecloud 在售套餐与库存

这个表解释了为什么「提高并发」要具体到业务类型。 同样是 4 核 4 GB，静态页能扛 1000 并发，动态页只有 25。商家宣传的并发数字基本都是第一行。

几个提升并发的技术手段，按性价比排序：

手段一，页面缓存。 把动态页的 HTML 缓存起来，让请求不进入 PHP。这是提升并发最有效的一招，代价是缓存失效逻辑要写对。命中率 80% 的页面缓存能把 PHP 并发需求降到原来的 20%。

手段二，静态化。 把不常变的页面生成静态 HTML，用 Nginx 直接返回。WordPress 站点可以用静态化插件把首页和文章页变成静态文件。效果和页面缓存接近，但省掉了缓存服务器的开销。

手段三，静态资源上 CDN。 这不直接提升 PHP 并发，但大幅减少回源请求，让有限的连接数用在真正的动态请求上。

手段四，把会话从 PHP 移到 Redis。 PHP 默认用文件存 session，每个请求都要读一次文件、加一次文件锁，在高并发下这个锁是明确的瓶颈点。改成 Redis 后并发能力通常能提升 30% 到 50%。

手段五，PHP 进程里装 OPcache。 每次请求都重新解析 PHP 文件是纯浪费。OPcache 把编译结果缓存在内存里，能把单请求 CPU 消耗降低 30% 到 50%。这是最便宜的一步，默认就该装：

; /etc/php/8.2/fpm/conf.d/99-opcache.ini
opcache.enable = 1
opcache.memory_consumption = 128
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 10000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 60

手段六，换常驻内存的运行方式。 Swoole、Workerman、RoadRunner 这类框架把 PHP 常驻在内存里，避免了每请求重新启动解释器的开销，QPS 通常能提升 3 到 10 倍。代价是要改代码，且需要业务本身适合常驻模型。

八、什么情况下并发上不去不是机器的问题

这一节按公开事实说明不适用的场景——机房位置、线路类型、计费方式、IP 资源，不评价任何商家好坏。

场景一：瓶颈在物理带宽，不是并发。 单台 VPS 的带宽是固定的。LAX-STARTER 是 2000 Mbps，LAX-LARGE 是 10000 Mbps。大流量场景下并发数再高，瓶颈也会回到带宽上。 替代方案：静态资源全上 CDN，只让动态接口回源；或者用多台机器做负载均衡。

场景二：瓶颈在机房位置和网络链路。 美西机房到国内访客要经过国际出口，晚高峰抖动是线路类型的固有属性。这时候并发数不是瓶颈，网络往返才是。替代方案：静态资源走 CDN 境内节点；或者按访客分布选更近的机房。

场景三：IP 资源受限的场景。 有些业务必须用多个独立 IP（多账号运营、爬虫轮换、需要不同 IP 段的场景），这时并发能力受限于你能拿到的 IP 数量，而每台机器的负载均衡还要考虑 IP 分配的均衡性。替代方案：把并发需求分散到多台机器，每台机器配固定的 IP 段，不要动态轮换。

场景四：计费方式限制了你做压测和横向扩展。 按流量计费的机型，压测本身要消耗配额（LAX-STARTER 每月 5000 GB），横向扩展要复制流量到多台机器。替代方案：用低成本的内部压测（小并发数长时间跑）替代高并发短时间压测，在夜间低峰时段做；扩展时优先把静态内容剥离出去。

场景五：共享 CPU 被超售。 如果压测时 CPU 使用率只有 40%，但延迟已经很高，且 top 里 steal time 持续大于 10%，说明宿主机把你的 CPU 份额让给了其他租户。这种情况下加并发只会让所有人一起变慢。替代方案：换提供独占核心的方案，或者确认商家的超售比例政策。

野草云 官网机型与实时报价

场景六：瓶颈在你的代码而不是机器。 一次请求里跑了个不带索引的全表扫描，加多少并发都是在放大这个问题。替代方案：先把慢查询解决，再谈扩容。加机器是掩盖问题，加索引是解决问题。

九、按你的配置对号入座：能扛多少人

给四类人的具体建议。

第一类：个人博客或静态展示站，月 PV 5000 以内。 用 1 到 2 GB 内存机型。RosCloud-02 是 29.99 美元每月，3 核 2 GB 内存、40 GB 硬盘、500 Mbps 带宽、每月 2048 GB 流量，每 GB 内存成本 14.99 美元。配置建议：pm.max_children 设 10，装 OPcache，静态资源上 CDN。这类站点的并发瓶颈几乎总是 CDN 和带宽，不是 PHP。

第二类：WordPress 内容站或小型商城，日均 PV 1 万到 5 万。 需要 4 GB 内存起步。RosCloud-03 是 39.99 美元每月，4 核 4 GB 内存、80 GB 硬盘、500 Mbps 带宽、每月 3072 GB 流量，每 GB 内存成本 10 美元、每 GB 硬盘成本 0.5 美元。配置建议：pm.max_children 设 25，装 OPcache 加页面缓存插件，会话移到 Redis。用压测确认：如果 25 并发时 P95 延迟小于 2 秒且无错误，那你的容量就是 25 并发，换算成同时在线约 200 人。

第三类：电商、论坛、API 服务，日均 PV 10 万以上。 需要 8 GB 以上内存，直接选高档位。LAX-MEDIUM 年付 800 美元折合每月 66.67 美元，8 核 8 GB 内存、160 GB 硬盘、10000 Mbps 带宽、每月 20000 GB 流量，每 GB 内存成本 8.33 美元、每 GB 硬盘成本 0.417 美元、每 TB 流量成本约 3.41 美元。配置建议：pm.max_children 设 50，MySQL max_connections 设 200，Redis 做会话和缓存，静态资源全 CDN。多机部署时用 Nginx 做负载均衡，用 least_conn 而不是轮询。

第四类：突发流量场景（秒杀、活动页、热点事件）。 突发流量下最需要的是「快速扩」，而 VPS 通常不提供弹性伸缩。替代方案：提前预热——活动前把页面全部静态化、缓存命中率提到 90% 以上、CDN 预热热点资源；同时准备一台备用机，配置和主机一致，活动前先跑一遍同样的压测。容量规划公式：峰值 QPS × 峰值持续秒数 ÷ 1024 = 需要预热的流量 GB，再对照套餐流量配额。

查 isvoro 在售套餐与库存

最后一条通用建议：每季度重做一次压测，并把结果记在文档里。代码在变、依赖在变、访客分布也在变，上季度的数字不能一直用。

按你的情况，下一步该看哪家

上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：

• 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 spinservers 当前机型与价格
• 做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 zenlayer 当前机型与价格
• 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 goodlyclouds 当前机型与价格

价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。

十、常见问题

问题一：为什么商家标 5000 并发我只能跑 50？ 那个数字通常是纯静态页或空响应的压测结果。你的业务要跑 PHP、查库、渲染模板，资源消耗高一个数量级。用本文第三节的估算表和第六节的压测方法对比。

问题二：并发上不去，是加内存还是加 CPU？ 看 top 里内存占用和 CPU 占用哪个先到顶。内存先到顶说明 PHP 进程数受限于内存，加核没用；CPU 先到顶说明是计算密集，加内存没用。

问题三：pm.max_children 设多少最合适？ 按第四节的三条约束取最小值，再往下留 30% 余量。设太高的典型症状是内存持续增长然后 OOM，表现为间歇 502。

问题四：压测结果准吗？ 要看压测有没有命中真实路径。压首页缓存命中和压一个要查数据库的详情页，结论完全不同。要压最重的那个接口。

问题五：为什么加了缓存并发上去了但数据不对？ 典型的缓存失效问题。发布新内容后旧缓存还在。解决方案是给缓存设短 TTL 加发布时主动失效，两层都做。

问题六：How many concurrent connections can a database handle?（数据库能扛多少并发连接） 看 max_connections 配置值，但更重要的是看实际能建立的连接数是否受内存限制。每个连接的基础内存开销约 1 MB，加上 sort_buffer 和 join_buffer，1 GB 内存的机器实际上撑不住 200 个连接。

问题七：WebSocket 和普通 HTTP 并发能一样算吗？ 不一样。HTTP 是短连接、请求结束就释放；WebSocket 每个连接常驻内存（每个连接几 KB 到几十 KB，加上你的会话数据）。一台 4 GB 机器能维持几千条空闲 WebSocket 连接，但每条连接都处理消息的话，CPU 会先卡住。

问题八：nginx 的 worker 进程数怎么配？ Nginx 的并发处理能力很强，一般 worker_processes auto 就够。真正限制 PHP 并发的是 pm.max_children。不要用 Nginx 的 worker_connections 算出 PHP 的并发。

问题九：CPU 使用率不高但请求超时，怎么查？ 三个方向：一是 pm.max_children 顶满了，请求在排队；二是数据库连接满了；三是某个锁在等待（MySQL 的 SHOW PROCESSLIST 里 State 显示 Waiting for table metadata lock）。三个都能在 5 分钟内定位。

问题十：怎么在扩容前知道要扩多少？ 用第三节的估算表先算出目标配置的 PHP 并发上限，用第六节的方法压测当前配置找到实际拐点，两者相除就是需要的倍数。然后按倍数选机型——注意选高一档比选低一档再加内存更划算，因为单位成本往往随规格下降。

问题十一：为什么别人的机器同样配置并发比我高？ 常见原因有三个：代码写法（有没有 N+1 查询）、是否装了 OPcache、是否用了页面缓存。这三个都是你能自己解决的，不需要换机器。 先按第七节把这三件事做了再比。

问题十二：并发和 QPS 换算的时候，响应时间用平均值还是 P95？ 用平均值会高估容量。用 P95 换算更保守，也更接近真实体验。举例：如果 QPS 是 100、P95 延迟是 0.4 秒，那需要的并发是 40 而不是平均值算出来的 20。