一、先说结论：并发上限不是厂商写的那个数
大部分 VPS 商品页上的「并发数」是不可信的，因为它没有定义。 「支持 1000 并发」可能指 1000 个 TCP 连接挂着不超时，也可能指 1000 个用户同时在页面上——这两者对机器的要求差着十倍以上。 你自己算出来的上限，才有决策价值。
并发上限由四个天花板中最矮的那个决定，不是由 CPU 核数决定：
| 天花板 | 决定因素 | 典型上限量级 | 撞线后的现象 |
|---|---|---|---|
| 内存天花板 | 常驻内存 × 可用比例 ÷ 单请求占用 | 32 GB 机器上 PHP-FPM 数百到上千 | 内存耗尽，进程被 OOM 杀掉，返回 502 |
| CPU 天花板 | 核心数 × 单请求 CPU 毫秒数 | 2 核跑动态页面约 100 到 300 QPS | 响应时间线性上升，队列堆积 |
| 数据库连接天花板 | max_connections ÷ 单请求连接数 | MySQL 默认 151，被每个 PHP worker 占一个 | Too many connections 报错 |
| 带宽天花板 | 端口带宽 ÷ 单请求响应体大小 | 1000 Mbps 理论 125 MB/s | 页面加载慢，静态资源拖垮动态接口 |
这四个里，PHP 类站点的实际瓶颈几乎总是数据库连接数，其次才是内存。 所以本文的顺序是：先算数据库连接，再算内存，最后才看 CPU 和带宽。
具体到商品库里的香港机型（渠道库快照 2026-11-11 16:30），能买到的最小一档是云途 HK.DS.M：350 元人民币每月，32 GB 内存、480 GB 硬盘、1000 Mbps 端口、10000 GB 月流量，CPU 标注 E5-2630 V2 × 1，磁盘 SSD；往上 DS.ES.F 是 399 元每月、同样 32 GB 内存 800 GB 硬盘、1000 Mbps 端口 10000 GB 流量、CPU 标注 4114 × 1；再往上是 DS.ES.C 的 700 元每月、64 GB 内存 800 GB 硬盘、2000 Mbps 端口 40000 GB 流量。 下面所有的推算，都基于这几个真实配置。
一个前提要摆在最前面：香港是全球互联网枢纽，国际出口带宽高度紧张。 同样一台机器放在香港和放在美西，单价差距是好几倍；如果你的用户全在欧美，机房位置带来的成本优势远大于在同城多榨出一点并发。**
二、算账：三个公式算出你的并发上限
这一节是全文的算法部分。三个公式，全部只需要你手上的配置就能算，不需要问厂商。
公式一：数据库连接上限 = max_connections ÷ 每请求占用的连接数
这是最容易被忽略、也最容易撞线的一个。 MySQL 的 max_connections 默认是 151，而每个 PHP-FPM worker 处理请求时通常独占 1 到 2 个连接。 也就是说，一台机器上开 16 个 PHP-FPM worker，实际能撑住的并发请求大约就是 151 ÷ 2 ≈ 75 个在途请求——再多就报 Too many connections。 这个数字与你的 CPU 核数、内存大小完全无关，一台 32 GB 的机器和一台 4 GB 的机器在这一点上表现完全一致。
公式二：内存并发上限 = 可用内存 ÷ 单请求内存占用
单请求内存占用需要实测，方法是压测时抓 RSS 的增量。 经验区间：WordPress + PHP-FPM 每个 worker 常驻 30 到 60 MB；Laravel 或带 ORM 的应用每个 worker 80 到 150 MB；纯静态 Nginx 每连接不到 1 MB。 按 DS.ES.C 的 64 GB 内存算：Linux 系统与服务常驻约占 25% 到 35%，可用内存约 42 到 48 GB；按每 worker 100 MB、并发 16 个 worker 计，内存可支撑约 420 到 480 个在途请求。 但这个 420 已经远超公式一的 75——所以结论很明确：这台 64 GB 的机器，瓶颈在数据库连接，不在内存。要提高并发，该动的是连接池和 worker 数，不是加内存。
公式三：CPU 并发上限 = 核心数 × 1000 ÷ 单请求 CPU 毫秒数
单请求 CPU 毫秒数同样要实测。 经验区间：PHP 动态页面 20 到 80 毫秒；Laravel 50 到 150 毫秒；静态 Nginx 0.5 到 2 毫秒；MySQL 简单查询 1 到 5 毫秒。 按 HK.DS.M 的 CPU 标注 E5-2630 V2 × 1 单核算，PHP 动态页面取 50 毫秒，1000 ÷ 50 = 20 QPS；如果换成 DS.ES.C 的 5120 × 1 单核加上典型 50 毫秒，理论上 20 QPS——这里必须说清楚：商品库里的 CPU 字段对云途机型给出的是型号加数量（如「E5-2630 V2 × 1」「5120 × 1」「8163 × 1」），是单路配置，而实际可用线程数与超线程策略需要按商家规格页确认；下面所有 QPS 推算都按「1 个可调度执行单元」保守计算，实际值以压测为准。**
把三个公式合起来，就是一张并发上限表：
| 机型 | 内存 | 磁盘 | 端口 | CPU 标注 | 数据库连接上限 | 内存上限（PHP，每 worker 100 MB） | CPU 上限（PHP，50 毫秒/请求） |
|---|---|---|---|---|---|---|---|
| 云途 HK.DS.M | 32 GB | 480 GB SSD | 1000 Mbps | E5-2630 V2 × 1 | 约 75 | 约 160 到 200 | 约 20 QPS |
| 云途 DS.ES.F | 32 GB | 800 GB SSD | 1000 Mbps | 4114 × 1 | 约 75 | 约 160 到 200 | 约 20 QPS |
| 云途 DS.ES.C | 64 GB | 800 GB SSD | 2000 Mbps | 5120 × 1 | 约 75 | 约 420 到 480 | 约 20 QPS |
| 云途 HK.DS.P | 64 GB | 1024 GB SSD | 2000 Mbps | 6248 × 1 | 约 75 | 约 420 到 480 | 约 20 QPS |
| 云途 HK.DS.S | 128 GB | 6000 GB SAS HDD | 2000 Mbps | 6248 × 1 | 约 75 | 约 850 到 950 | 约 20 QPS |
这张表里最值得看的一列是「数据库连接上限」——它整列都是 75，因为它跟机器档次完全无关。 这解释了一个现象：为什么很多人在香港买了 64 GB 的机器，网站却还是几十并发就 502。 不是机器不行，是 MySQL 的默认连接数把门卡住了。
所以真正能提高并发的三个动作是：调大 max_connections、让 PHP-FPM worker 复用连接（持久连接）、以及给静态资源上 CDN 或 Nginx 缓存。 前两个不花钱，第三个花钱但一劳永逸。
顺便把流量账也算一下，因为并发和流量是一体两面。 按每页响应体 200 KB 算，1000 Mbps 端口理论上限是 125 MB/s，即每秒约 640 个这样的页面；但真正决定账单的是月流量额度。 HK.DS.M 的 10000 GB 流量，若每页 200 KB，一页约消耗 0.0002 GB，10000 GB 理论上够约 5000 万次页面传输。 实际要打八折，因为图片、JS、CSS、API 轮询都会额外消耗。 DS.ES.C 的 40000 GB 流量是 HK.DS.M 的四倍，端口也从 1000 Mbps 升到 2000 Mbps，每 TB 流量 17.92 元比 HK.DS.M 的 35.84 元低一半——这就是「流量单价随升档下降」的算术原因。
最后补一个「并发不等于访问量」的换算，这一步不做容易买错。 一次页面访问往往不是一个请求：一次首页浏览通常包含 1 个 HTML、10 到 20 个静态资源、3 到 8 个 XHR 接口，也就是 15 到 30 个 HTTP 请求。 所以「每天 1 万访客」不等于「每天 1 万并发」——正确的换算是：1 万访客 × 20 个请求 × 每人平均停留 3 分钟 = 600 万次请求，摊到 24 小时是平均 0.7 QPS，摊到每天最忙的 4 小时是平均 4.2 QPS，摊到活动开始那一分钟（假设 20% 的访客在 5 分钟内涌入）就是 200 QPS 的峰值。 这就是为什么很多日访问量上万的站，日常很轻、促销时却 502。 采购时该按峰值算，不是按日均算。**
按这个换算再回看三个档位：HK.DS.M 约 20 QPS 的保守上限，对应「峰值 200 QPS 的活动」是不够的；DS.ES.C 同样受限于单执行单元，但它的内存能支撑 420 到 480 个在途请求，加上多台机器水平扩展，是中型业务的正确形态；HK.DS.S 的 128 GB 内存能撑到 850 到 950 个在途请求，适合承接大内存单体。
三、压测：怎么把上限真实测出来
公式算出来的只是估算，要拿到真数字必须压测。 这一节给可复制的操作步骤。
工具选择：wrk（轻量、适合纯 HTTP 压测）、ab（ApacheBench，参数直观）、hey（Go 写的，多核性能好）、jmeter（图形界面，适合有复杂请求链的场景）。 对 VPS 这种小机器，推荐先用 wrk，它本身开销极小，不会把客户端 CPU 变成瓶颈。
标准压测流程，四步：
# 1. 确认压测端与被测端不同机（否则测的是回环，网络指标没意义）
# 2. 预热：先跑 30 秒，让 JIT、连接池、缓存进入稳态
wrk -t2 -c50 -d30s http://目标/healthz
# 3. 阶梯加压：每档加并发，记录 QPS 与延迟
for c in 20 50 100 200 400; do
echo "=== concurrency=$c ==="
wrk -t2 -c$c -d30s --latency http://目标/healthz
done
# 4. 压测同时在目标机采样资源压测期间在目标机上必须同时采样这四个数，否则等于没测：
# 内存与 swap：看有没有开始换页（一换页，延迟就雪崩）
vmstat 1 60
# CPU 利用率与上下文切换
mpstat -P ALL 1 60
# 网络吞吐与连接数
sar -n DEV 1 60
ss -s
# 应用层：PHP-FPM 活跃 worker 与请求队列看结果的方法，比看数字更重要。 三种典型的压测曲线，各自对应一个明确的结论：
| 曲线形态 | 表现 | 结论 | 动作 |
|---|---|---|---|
| 平坦后陡降 | 并发从 20 涨到 50 时 QPS 不再上升，延迟翻倍 | CPU 打满 | 升 CPU 档位，或做缓存让动态计算变静态 |
| 延迟先涨、QPS 后跌 | 延迟随并发线性上升，错误率从 0 跳到 5% | 数据库连接耗尽 | 调大 max_connections，加连接池 |
| 尾部抖动 | 平均延迟正常，但 p99 偶尔冲到数秒 | 单个慢查询或 GC 停顿 | 看慢查询日志、给热点表加索引 |
p99 是比平均值重要得多的指标。 平均值 50 毫秒、p99 三秒，说明每百个请求里就有一个用户等了六秒——对做购买决策的电商页面来说，这个体验就是「下单时页面卡住」。 验收时一定要看 p99，不要只看平均值。**
压测的三个纪律，别踩。 第一，压测流量会真扣月流量额度——按商品库口径，1000 Mbps 端口档超额 200 元、2000 Mbps 端口档超额 500 元，用云途 40000 GB 流量档压测比用 10000 GB 档安全。 第二，压测端必须和被测端分属不同机器，否则测的是本地回环。第三，压测时间选业务低峰，避免和真实用户撞车导致数据失真。
再补一个常被跳过的步骤：基线测量。 在加压之前，先测「空载」状态下系统的固有开销——这组数字是后面所有对比的参照系。 具体做法：什么都不压，只在目标机上采样 60 秒，记下 vmstat 的空闲内存、mpstat 的 CPU 空闲率、sar -n DEV 的基础网络流量。 没有基线，你看到「并发 200 时 CPU 90%」也无从判断是应用吃掉的还是系统吃掉的。
还有一个压测结果容易被误读的地方：压测端自身的瓶颈。 用一台配置普通的机器去压目标机时，如果压测端的 CPU 已经 100%，那么测出来的 QPS 是压测端的上限，不是目标机的上限。 验证办法很简单：把压测并发数降一半，如果 QPS 跟着降了一半，说明压测端是瓶颈；如果 QPS 不变而延迟上升，说明目标机是瓶颈。 这个自检必须在正式压测前做，否则整轮数据都不可信。**
四、七项验收阈值：并发能力的合格线
这一节给的是可判定的是非标准，不是「感觉还行」。 压测完成后逐项对表，不达标就是配置不够或架构有问题。
| 编号 | 验收项 | 阈值标准 | 怎么测 | 不达标怎么办 |
|---|---|---|---|---|
| 1 | 稳态 QPS | 目标并发的 1.2 倍负载下，QPS 不低于预估值的 80% | wrk 阶梯压测取 30 秒稳定值 |
加缓存或升档 |
| 2 | p99 响应 | p99 < 500 毫秒 | wrk --latency 或压测平台报告 |
优化慢查询、加索引 |
| 3 | 错误率 | 5 分钟压测内错误率 < 0.5% | 压测输出中的 socket errors / non-2xx | 查连接池与超时设置 |
| 4 | 内存谷值 | 压测中最低可用内存 ≥ 总内存的 15% | vmstat 1 的 si/so 列与 free -h |
减 worker 数或升档 |
| 5 | swap 使用 | 压测期间 swap 换入换出速率持续为 0 | vmstat 的 si、so 列 |
加内存，这是硬伤 |
| 6 | 数据库连接 | 峰值连接数 ≤ max_connections 的 70% | SHOW STATUS LIKE 'Threads_connected' |
调大 max_connections 或加连接池 |
| 7 | 带宽占用 | 稳态带宽占用 < 端口带宽的 60% | sar -n DEV 1 |
静态资源上 CDN |
第 5 项要重点解释，因为它是判断「该升档还是该优化」的分水岭。 如果压测中 swap 开始换页（si、so 持续不为 0），说明内存已经不够用，系统的响应时间会出现数量级的恶化——这时候加内存是唯一有效的解，加 CPU 无效。 反过来，如果内存充裕但 CPU 打满（vmstat 的 r 队列长期大于 1），那加内存是浪费，该加的是执行单元或做缓存。
第 6 项的 70% 阈值不是随便定的。 MySQL 在连接数接近 max_connections 时，为新连接分配的排队延迟会明显上升；留 30% 余量是给管理连接、监控采集和运维操作留的空间。 同时也要提醒：max_connections 调大是有代价的——每个连接在 MySQL 侧都有线程栈和排序缓冲开销，调到 500 而机器只有 2 GB 内存，会把机器拖垮。 所以调大它之前先确认内存余量。
第 7 项对大带宽场景最关键。 1000 Mbps 端口在 60% 占用下就是 75 MB/s，扣掉 TCP/TLS 开销实际吞吐约 70 MB/s；如果你的业务同时提供 5 MB 的安装包下载，一台机器的带宽会被迅速吃光，此时静态资源必须上 CDN 或对象存储。**
还有一个常被忽略的验收维度：并发测试要覆盖「突发」而不只是「稳态」。 真实的电商流量在开团那一分钟是平时的十倍。 建议额外做一次 60 秒的突发测试：直接把并发拉到稳态上限的 2 倍，看错误率是否仍低于 0.5%、队列是否在测试结束后 5 分钟内排空。 排空速度比峰值吞吐更重要——排不空的队列意味着下一个高峰会更糟。
五、什么时候不该选香港 VPS 扛并发
这一节讲反面。判断依据只用公开事实——机房位置、线路类型、计费方式、IP 资源、磁盘类型，不评价任何商家好坏。
不该选的情况一：你的负载是静态内容分发。 事实依据：1000 Mbps 端口、10000 GB 月流量的档位，静态内容的瓶颈在出口带宽和流量额度，不在 CPU 和内存。 用一台 350 元的机器去分发大量下载或图片资源，是把最贵的资源（流量）用在了最不值的方式上。 替代方案：静态资源上 CDN 或对象存储，VPS 只跑动态接口；这样 10000 GB 的额度可以只留给动态请求。
不该选的情况二：你的负载是长连接型实时业务。 事实依据：实时音视频、在线游戏、IM 长连接的特点是连接数远大于请求数，单条连接持续时间长但带宽占用低——这类负载考验的是单 IP 的连接承载能力和 NAT 层的会话表容量，而商品库中香港方向机型的 IP 说明标注为「IPv4（原页未注明具体数量）」，单一 IP 意味着所有长连接都从同一个源地址出去。 替代方案：选明确标注多 IP 或大连接数上限的机型，或用 CDN/负载均衡做前置分发，把长连接分散到多个源 IP。
不该选的情况三：你的负载是重 IO 的数据库。 事实依据：商品库对云途机型的磁盘类型标注不统一——HK.DS.S 标注 SAS HDD，其余多数标注 SSD。 SAS HDD 的随机写延迟是毫秒级，SSD 是微秒级；高并发下的数据库写入正是随机写，把数据库放在机械盘标注的机型上，并发越高，锁等待和 IO 等待越长。 替代方案：数据库单独用 SSD 机型（DS.ES.C、HK.DS.P、DS.ES.D 均标注 SSD），大容量的机械盘机型只做备份和对象存储。**
不该选的情况四：你的用户主要在欧美。 事实依据：香港是全球互联网枢纽、国际出口带宽紧张；同一份商品库里，LAX-STARTER 年付 200 美元折合月价 16.67 美元、每 GB 内存 8.33 美元、每 TB 流量 3.413 美元。 按业务负载类型看：如果你的负载吃流量，美西每 TB 流量 3.413 美元（约 24 元人民币）低于香港起步档的 35.84 元；如果吃内存，香港的 10.94 元每 GB 内存远低于美西的约 59 元每 GB。 替代方案：先按负载类型判断机房位置，把「并发能力」和「机房位置」这两个变量分开决策，别把预算全压在一台上。
反过来，也有不该靠「加机器」解决并发的情况，这里一并写清楚。 不该硬扛的情况：单台机器的 CPU 已经打满、但 QPS 没上去，同时带宽占用很低——这说明瓶颈是业务代码本身。 替代方案：先做缓存（Redis 缓存热点查询、Nginx 缓存静态页）、再做异步化（队列削峰、把非关键路径挪出主流程），最后才是加机器。 盲目升档买来的机器，会把同样的低效代码跑得更贵。
六、连接数、进程数与参数怎么配
这一节是配置层：把第二节算出来的上限，变成具体的参数。
PHP-FPM 的三个核心参数，直接决定并发上限：
; /etc/php/*/fpm/pool.d/www.conf
; pm = static 时：pm.max_children 才是真正的并发上限
pm = dynamic
pm.max_children = 24 ; 建议先从 CPU 核数 × 4 起步，压测后调整
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 12
; 每个 worker 的内存上限，超出就回收，避免单个请求拖垮整机
request_terminate_timeout = 60PM 模式怎么选：static（固定进程数，内存占用可预测）、dynamic（按需增减，适合流量波动）、ondemand（有请求才起进程，适合低频 API）。 对并发敏感的站点，static 模式最稳——因为它的并发上限是一个确定的数字 pm.max_children，你可以直接对着数据库连接数做匹配。
MySQL 侧的配套参数，改之前先算内存：
[mysqld]
max_connections = 300 ; 前提是内存余量够
innodb_buffer_pool_size = 2G ; 约为可用内存的 50% 到 70%
max_connections = 300
wait_timeout = 300
thread_cache_size = 64一个关键换算：每 1 个 MySQL 连接大约需要 1 MB 到 2 MB 的线程栈加缓冲开销。 所以在 32 GB 内存的机器上，max_connections = 300 大约要预留 300 MB 到 600 MB，这是可接受的；但在 2 GB 的机器上设 300 就是灾难。 这里给一个可以直接抄的经验公式：max_connections ≈ 可用内存 MB ÷ 2 ÷ 每连接 MB，并用 pm.max_children 不超过它的 70%。
Nginx 的连接参数：
worker_processes auto; ; 按 CPU 核数
worker_connections 4096; ; 单 worker 连接数
worker_rlimit_nofile 8192; ; 系统级文件描述符上限
events {
use epoll;
multi_accept on;
}还有一个容易被忽略的系统层限制：文件描述符。 Linux 默认单进程文件描述符上限常常是 1024，一个 Nginx worker 要维护连接、读日志、连上游，很容易撞上 Too many open files。 修正方法是提高系统的软限制并同步改 Nginx 的 worker_rlimit_nofile。
# 查看当前限制
ulimit -n
# 临时提高
ulimit -n 65535
# 永久生效
echo "* soft nofile 65535" >> /etc/security/limits.conf
echo "* hard nofile 65535" >> /etc/security/limits.conf这三个层的参数必须一起改，否则会出现「改了 MySQL 但 PHP 连不上」或「改了 Nginx 但系统拒绝」的情况。 改完的验证顺序是：先看 SHOW VARIABLES LIKE 'max_connections' 是否生效，再跑一次 wrk 看错误率，最后看 vmstat 有没有开始换页——三步都过，才算真的调完了。
七、常见误区与常见报错
误区一：以为并发数是商品页上的一个固定指标。 商品页上的并发数字没有定义标准，不能作为采购依据。 自己用三个公式推、用压测校，才是对的。
误区二：以为加内存就能加并发。 对 PHP-FPM 站，加内存只在 worker 数受限于内存时才有效；如果瓶颈是 max_connections（默认 151），加 64 GB 内存进去，并发还是上不去。
误区三：以为 QPS 一定随并发线性上升。 QPS 只在 CPU 未饱和前随并发上升；一旦饱和，多加的并发只增加排队延迟，QPS 不再增长——这个拐点就是你的真实上限。**
报错一：Too many connections。 MySQL 连接数打满。解法是分两步：先把 max_connections 调到内存允许的上限，再给 PHP-FPM 开持久连接，减少重复握手。
报错二：mysqlnd 或 PDO 报 SQLSTATE[08004] [2002] Connection refused。 数据库没起来或连接数已满。 先用 systemctl status mysql 确认服务状态，再用 SHOW PROCESSLIST 看是不是有大量 Sleep 连接占着。
报错三：502 Bad Gateway 高并发时集中出现。 通常是 PHP-FPM 的 pm.max_children 太小，请求排队等不到 worker 就超时；也可能是 worker 被 OOM 杀掉。 查法是看 /var/log/php-fpm.log 里有没有 Allowed memory size exhausted 和 Server reached pm.max_children。**
报错四：Killed / OOM。 内存耗尽。 查 dmesg -T | grep -i "killed process" 找出被杀的进程，调低 pm.max_children 或加内存。
报错五：压测时延迟正常，但生产环境变慢。 多半是压测没覆盖真实场景——真实用户有图片、有 CDN 回源、有数据库热点行。 加上慢查询日志（slow_query_log = ON，long_query_time = 1）再看。
报错六：Nginx 报 worker_connections are not enough。 文件描述符或 worker_connections 不够，按上一节的命令提上去，同时确认 worker_processes 和 worker_rlimit_nofile 一致。
八、按用途和预算落地：三类人的具体结论
前面七节给的是算法、阈值与排错，这一节给结论。每类人给出明确配置、明确月费预算和明确的验收步骤，不写「视情况而定」。
第一类：个人站点、博客、小型展示站，目标是几百人同时看而不是几千人。 结论：云途 HK.DS.M，350 元/月，32 GB 内存、480 GB 硬盘 SSD、1000 Mbps 端口、10000 GB 月流量，CPU 标注 E5-2630 V2 × 1。 为什么是它而不是更贵的：你的并发瓶颈在数据库连接（公式一约 75），不在内存（公式二给到 160 到 200），更不在 CPU（约 20 QPS 已经远超个人站需求）。 升级到 DS.ES.F（399 元/月）唯一值得的理由是硬盘从 480 GB 变成 800 GB、每 GB 硬盘从 0.729 元降到 0.499 元——如果你的站点有大量图片和备份文件，加这 49 元是划算的。 具体配置动作：MySQL max_connections 设 150、PHP-FPM pm 用 static 且 pm.max_children 设 16、静态资源上 CDN。 验收跑第四节的七项，重点是第 1 项 QPS ≥ 16、第 4 项内存谷值 ≥ 15%、第 6 项连接峰值 ≤ 105。 注意商品库快照显示该机型当前库存为 0，实际是否可下单以官网当日显示为准。**
第二类：中型业务（企业官网、电商、论坛、SaaS），目标是几百到一两千并发。 结论：云途 DS.ES.C，700 元/月，64 GB 内存、800 GB 硬盘 SSD、2000 Mbps 端口、40000 GB 月流量，CPU 标注 5120 × 1；存储吃紧就换 HK.DS.P，750 元/月，64 GB 内存、1024 GB 硬盘 SSD、2000 Mbps 端口、40000 GB 月流量，CPU 标注 6248 × 1。 选这一档的理由有三条具体数字：每 GB 内存 10.94 元与 HK.DS.M 持平（加一倍内存不加价）、每 TB 流量 17.92 元比 HK.DS.M 的 35.84 元低一半、端口从 1000 Mbps 翻到 2000 Mbps。 配置动作：MySQL max_connections 调到 300 并把 innodb_buffer_pool_size 设成 2G、PHP-FPM pm.max_children 设 48、Nginx worker_connections 设 4096、静态资源全部上 CDN。 验收重点：第 1 项 QPS ≥ 20、第 2 项 p99 < 500 毫秒、第 5 项 swap 换入换出为 0、第 7 项带宽占用 < 1200 Mbps。
第三类：高并发接口（活动页、秒杀、API 网关），目标是把并发交给架构而不是交给单机。 结论：单台 DS.ES.C 或 HK.DS.P 做入口 + 应用层，同时用 DS.ES.S（800 元/月，128 GB 内存、6000 GB 硬盘、2000 Mbps 端口、40000 GB 月流量，CPU 标注 6248 × 1）做缓存与队列层；入口层用 HK.DS.M（350 元/月）做负载均衡与静态分发。 合计 1850 元/月。 这里必须点明 HK.DS.S 的取舍：它每 GB 内存 6.25 元是全表最低、每 GB 硬盘 0.133 元也是全表最低，但磁盘类型标注为 SAS HDD——所以它适合做缓存、消息队列、文件存储，不要用它跑主数据库。 配置动作：数据库用 DS.ES.C、Redis 集群用 HK.DS.S、Nginx 做静态分发并开启缓存、入口层用 HK.DS.M。 验收重点：第 3 项错误率 < 0.5%、第 5 项 swap 换入换出为 0、第 4 项内存谷值 ≥ 15%、追加一次 60 秒突发测试看队列能否在 5 分钟内排空。**
如果你不属于这三类，还有两个通用动作。 第一个动作：无论买哪一档，先月付一个月，把第四节的七项验收跑完，把真实的 QPS 曲线和 p99 数字拿到手，再决定升档还是加缓存——年付买错的沉没成本是一整年。 第二个动作：确认你的用户里真的需要香港机房——香港是全球互联网枢纽，国际出口带宽高度紧张，同样一台机器在香港和美西的单价差距是好几倍，机房位置是物理事实，配置是算术结论，两条都算清楚再下单。**
按你的情况，下一步该看哪家
上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：
- 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 数脉科技 当前机型与价格
- 做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 joysol 当前机型与价格
- 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 tmhhost 当前机型与价格
- 跑游戏服或实时业务：看上行抖动与防御能力，普通套餐往往不达标。看 野草云 当前机型与价格
价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。
九、常见问题
问：香港VPS能扛多少并发？
答：先看瓶颈在哪。对 PHP 类的站点，瓶颈几乎总是数据库连接数而不是配置。 MySQL 默认 max_connections 是 151，每个 PHP-FPM worker 独占 1 到 2 个连接，所以一台机器的实际上限大约是 75 个在途请求——这个数字跟你买的是 32 GB 还是 128 GB 无关。 调大 max_connections、开持久连接、静态资源上 CDN，三个动作做完，上限能提升数倍。
问：32 GB 内存的香港 VPS 能撑多少 QPS？
答：对 PHP 动态页面，按商品库口径的单执行单元配置保守估约 20 QPS；对纯静态 Nginx，单核可达数百到上千 QPS。 关键在于单请求耗时：PHP 动态页面 20 到 80 毫秒，静态页面 0.5 到 2 毫秒。 所以「QPS 低」通常不是机器不行，而是你的页面里有数据库查询没走缓存。 先加 Redis 缓存再谈升档。
问：并发上不去，是加内存还是加 CPU？
答：看 vmstat。 r 队列长期大于 1、CPU 满而内存有余量，加 CPU；si/so 持续不为 0、内存被换页，加内存。 两个都满说明应用本身效率低，先做缓存和异步化。
问：香港 VPS 的带宽能支撑多少并发？
答：1000 Mbps 端口理论 125 MB/s，扣掉协议开销实际约 70 到 100 MB/s，按每页 200 KB 算是每秒 350 到 500 个页面。 但账单上的约束是月流量额度：HK.DS.M 是 10000 GB，DS.ES.C 是 40000 GB。 大带宽场景必须先上 CDN，把动态请求的流量额度省下来。
问：压测工具用哪个？
答：先用 wrk。 它本身开销极小，适合 VPS 这种小机器；ab 参数直观适合新手；复杂请求链用 JMeter。 压测时必须在目标机同时采样 vmstat、mpstat、sar，否则拿到的数字没有意义。
问：怎么知道现在的真实并发是多少？
答：看日志里的在途请求数。 Nginx 的 $nginx_status 里 Active connections 是当前在途连接；应用侧可以看 PHP-FPM 活跃 worker 数除以 pm.max_children 得到利用率。 利用率长期低于 30% 说明机器买大了，高于 80% 说明该升档了。
最后再提醒一次价格口径：以上所有价格与配置来自渠道库快照（2026-11-11 16:30 抓取），各机型的实际报价、库存、续费价、IP 数量与退款政策请以官网当日显示和客服回复为准。
喜欢 
高兴
鬼脸
呵呵
无聊
伤心
