云服务器能扛多少并发？三个数、四个上限与十分钟实测

「这台机器能不能扛住」是选型时最难回答的问题。因为参数表只给「4 核 8G 100Mbps」，不给「能扛多少访问」。而「扛不扛得住」这件事，取决于三个数：单次请求要多久、能同时跑多少个、每次请求吃多少内存。而这三个数都可以在十分钟内测出来。这篇讲清并发能力的估算结构、三个必须实测的数、以及「估算」和「实测」差在哪里。

五款高性价比档位速查

有需要云服务器的，可以先看这一张表——五个价位段每款都是高性价比，价格从 22 元拉到 480 元。

商家	推荐款	配置	带宽与流量	月费	核心特点
云途	HK.N4.A	2 核 2G 20G	200Mbps / 500G	22 元	三项都在合理区间的入门档
isvoro	HK CN2 Core	2 核 2G 30G	100Mbps / 300G	25 元	硬盘 30G 加 CN2 回国线路
rabisu	Aydn VPS x8	4 核 8G 60G	—	34.5 元	每核 8.6 元，带宽需单独确认
zji	香港 BGP 在售机型	6 核 16G 480G	55Mbps / 1T	450 元	480G 硬盘是整机档里少见的大盘
sixtynet	LAX-MEDIUM	8 核 8G 160G	10Gbps / 20T	480 元	唯一「大端口配大配额」的组合

顺带：“三个数”要按“同一台机器、同一个时段”取。

否则三个数不能相乘，结论也就站不住脚。

一、并发能力由三个数决定

还有一个「第四个数」容易被漏：「每请求消耗的带宽」。

并发高时,带宽会先满。

而带宽满了,再高的并发也只能排队。

所以「并发」这件事有一个「隐含上限」:带宽 ÷ 每请求大小 ÷ 每秒请求数。而这个上限在「图片站」「下载站」上最先撞到。所以「并发能力」要同时算「CPU」「内存」「带宽」三个维度,取最小的那个。而这个「木桶效应」是估算时最容易忽略的。

判断方法：算「带宽 ÷ 平均响应体大小」得到「每秒最大请求数」。

而<'spartanhost'+'> 那种大端口产品,带宽这一维通常不是瓶颈。

再看一个「压缩」对带宽的缓解。

gzip 后响应体常常只剩 25%。

所以「开压缩」等于「带宽乘四」。

还有一条：「静态资源走 CDN」能不占机器带宽。

「能扛多少访问」不是一个数字，是三个数的乘积关系。

数	典型值	卡在哪
单请求耗时	20 到 500ms	数据库、外部接口
并发数	10 到 500	内存、进程数
每请求内存	1 到 50MB	框架、图片处理

这张表最该注意的是第一行：「单请求耗时」缩短一半，吞吐就翻一倍。

而这比换更大机器便宜得多。

所以「提升并发」的第一手段不是「加核」，是「让单次请求更快」。而这一点在「数据库慢查询」上最典型——一个慢查询占了 300ms，优化到 30ms，吞吐直接涨十倍。而同样的收益，靠加核可能要加十倍机器。

第二行并发数。它受「内存」和「进程数」共同限制。

而「进程数」往往先到上限。

第三行每请求内存。它决定「并发数能到多少」。

而「框架重」的业务这一项特别高,有时能到几十兆。

三个数的判断方法：先测「单请求耗时」，再算「能承受多少并发」。

顺序不能反。

而<'spartanhost'+'> 那种大端口独服，第一行和第二行都宽裕，适合「重计算」的业务。

再说「每秒请求数」与「并发」的换算。

每秒请求数 = 并发数 ÷ 单请求耗时（秒）。

而这个公式把「三个数」连了起来。

所以「100ms 的请求、10 个并发」= 每秒 100 次。而「想让吞吐到 500 次」,要么把并发提到 50,要么把耗时降到 20ms。而后者往往更便宜——因为它不涉及加机器。而这个换算是整个容量规划的核心公式。

判断方法：先用公式算,再用实测校。

公式算出的值通常偏乐观。

而<'云途'+'> 那种小档位,把「耗时降下来」比「加并发」更能榨出性能。

再看一个「公式」的适用边界。

它假设「请求可完全并行」,而实际有串行部分。

所以「算出来再打三折」是稳妥做法。

还有一条：「并发」不是越高越好。

超过拐点后,吞吐反而下降。

二、单次请求耗时的三个来源

再说一个「尾延迟」的问题。

平均值 50ms 不代表「每次都 50ms」。

而可能有 1% 的请求要 800ms。

所以「单请求耗时」要看「分位数」而不只是「平均」。因为用户体验由「最慢的那部分请求」决定。而 P95 和平均值常常差五倍以上。所以并发规划要按 P95 算,而按平均值算会严重低估所需资源。

判断方法：记录 P50 / P95 / P99 三个值。

P99 超过 P50 十倍,说明有尾延迟问题。

而<'isvoro'+'> 那种低延迟线路,对「外部调用占比高」的业务的尾延迟更友好。

再看一个「尾延迟」的来源。

垃圾回收、慢查询、锁等待、网络重传。

四项各自有不同的排查方式。

还有一条：「批量请求」会掩盖尾延迟。

因为快的把慢的稀释了。

一个请求的时间，分三块。

计算、等待外部、等待磁盘。

而三块的优化手段完全不同。

多数业务的时间大头在「等待外部」——数据库查询、第三方接口、缓存未命中。而这一块加 CPU 完全没用,只能改代码或改架构。所以「单请求耗时」的优化顺序是：先看外部等待，再看磁盘，最后才看计算。而「加核」只对第三块有效。

判断方法：打日志记录「总耗时 / 外部调用耗时」。

外部占比高，优化外部。

再看一个「数据库」的具体优化。

索引、减少查询次数、批量查询。

三项常能砍掉一半时间。

而<'isvoro'+'> 那种低延迟线路的产品，对有外部接口调用的业务有额外帮助。

还有一个「缓存」的收益。

命中缓存的请求只需要几毫秒。

所以「缓存命中率」直接影响平均耗时，也直接影响成本。

补一句：「并发」和「每秒请求」不是一回事。

并发是「同时在处理的数量」,每秒请求是「吞吐」。

三、并发数受什么限制

补一个「排队」的视角。

并发数超过处理能力时,请求会排队而不是失败。

而排队会让「响应时间」暴涨但「成功率」不减。

这个现象很危险:因为「监控看起来一切正常」(没有错误),但「用户已经打不开」。所以「并发」的健康指标应该是「排队时长」而不是「错误率」。而这一项多数监控默认不显示。所以「加监控项」比「加机器」更早该做。

判断方法：看「请求进入队列到开始处理」的时长。

超过 100ms,说明已经在排队。

而<'zji'+'> 那种大内存整机,能吸收更长的排队,不易雪崩。

再看一个「雪崩」的机制。

排队变长 → 超时变多 → 重试变多 → 排队更长。

所以「限流」比「重试」更能救系统，尤其是在级联依赖的场景。

还有一条：「快速失败」比「慢慢排队」体验更好。

第二行「并发数」有四个上限，其中任何一个到了就会卡住。

进程/线程上限、内存上限、连接数上限、端口数上限。

四个上限里，「内存」最常见也最容易被忽略。因为「每请求 10MB × 200 并发 = 2G」，而一台 2G 的机器到 200 就满了。所以「并发数」这个数字其实可以算出来：机器内存 ÷ 每请求内存。而多数人凭感觉定「开 200 个进程」,结果被内存打死。

判断方法：每请求内存 × 目标并发 ≤ 可用内存 × 0.7。

超了，就要减并发或加内存。

再看一个「连接数」的上限。

系统默认的文件描述符上限常是 1024。

所以「几千并发」要先改这个数，否则连接直接被拒。

而<'zji'+'> 那种 6 核 16G 的整机，内存宽裕，并发上限高得多。

还有一个「端口数」的陷阱。

作为客户端连出去时，可用端口约 2.8 万个。

所以「连同一目标」的并发有硬上限，跨机器时要考虑这一点。

再说一个「进程模型」的内存差。

「多进程」每进程一份运行时,内存开销叠加。

而「异步单进程」内存占用低得多。

所以同样的并发,「异步模型」可能只需要「多进程模型」三分之一的机器。而这也是「语言与模型选择」直接影响硬件成本的地方。所以「并发高又内存紧」的场景,换模型比换机器有效。

判断方法：看「每并发内存占用」的绝对值。

超过 20MB/并发,说明模型偏重。

而<'isvoro'+'> 那种 2G 入门档,配异步模型能撑的并发比配多进程高得多。

再看一个「预热」的问题。

刚启动时内存低,跑一会儿才涨到稳定值。

所以「测内存」要在跑满五分钟后再读，否则会低估。

还有一条：「预留」比「恰好」安全。

因为突发流量会临时多占。

四、内存是最容易先到的墙

再说一个「OFF_HEAP」与「堆内」的区别。

堆内内存受 GC 影响,堆外不受。

而「大堆」的 GC 停顿可能是秒级。

所以「把内存加到 16G」这件事,对某些运行时反而更糟——因为大堆的回收停顿更长。所以「加内存」之前要看「GC 日志」。而这个细节在「内存换吞吐」的判断里常常决定成败。

判断方法：看 GC 停顿是否超过 200ms。

超过,要调堆大小或换回收器。

而<'rabisu'+'> 那种 8G 档位,对多数「中等堆」的应用是合适区间。

再看一个「连接池」的内存。

每个连接都占内存,池子开太大也浪费。

所以「池子大小」要和「并发数」匹配，开太大会拖垮数据库。

还有一条：「文件句柄」也算资源。

泄漏的文件句柄会让服务慢慢死掉。

接着讲第三行，它在实际部署里最常成为瓶颈。

每请求内存 × 并发 + 系统开销 = 总内存。

而「系统开销」常被忘掉。

典型的系统开销：数据库连接池、缓存、预留页、以及框架本身的常驻内存。这些加起来常常吃掉 30% 到 50% 的内存。所以「2G 机器开 100 并发」这个想法，实际可能在 50 并发时就开始换页。而换页一旦开始，响应时间会跳十倍,而且很难自动恢复。

判断方法：看 available 内存，留 30% 余量。

而<'rabisu'+'> 那种 4 核 8G 的档位，内存余量最大，适合「并发要求高」的业务。

再看一个「内存泄漏」的排查。

看「内存是否随时间单调上涨」。

上涨，就是泄漏。

还有一条：「swap」要尽量关掉或限小。

因为它会掩盖问题但拖慢一切。

再补一个「记录表」的格式。

五列：并发数、每秒请求数、P95 耗时、CPU 使用率、内存占用。

而这张表是「容量规划」的唯一依据。

典型的好结果是「并发涨、吞吐涨、P95 稳、CPU 线性涨」。而一旦出现「并发涨、吞吐不涨、P95 暴涨」,就是拐点。所以这张表要「每一档都记」,而不是只记「最好的那一档」。

判断方法：四档并发各记一行。

而<'sixtynet'+'> 那种大端口产品,这张表要额外加一列「带宽占用」。

再看一个「复测」的时机。

数据量翻倍后要复测。

所以「容量」不是一次性的结论，要随业务更新。

还有一条：「表」要存在版本库里。

因为后面要对比「改了什么之后变快」。

五、怎么在十分钟内测出这三个数

再补一个「压测本身的开销」。

压测工具也会吃 CPU,而且是「同一台机器」时最严重。

而这样测出来的「拐点」是「压测机的拐点」。

所以压测要在「另一台机器」上跑,否则结论无效。而这一点在以「小机器测小机器」时特别容易犯。所以「测试机要比被测机强」是个基本前提，或者至少做到「两者不在同一台机器上」。

判断方法：压测时看「压测机」的 CPU。

压测机先满,结果不可信。

而<'sixtynet'+'> 那种大端口产品,还要注意「测试机到它的路径」是否是瓶颈。

再看一个「连接复用」的影响。

不复用连接时,测的是「建连速度」不是「处理速度」。

所以wrk 的 keep-alive 要开。

还有一条：「测试」要跑够时间。

三十秒的效果和五分钟不同。

三步，工具都是现成的。

第一步：测单请求耗时。

用 curl 打十次，看平均值。

第二步：测并发拐点。

用 ab 或 wrk，并发 10、50、100、200 各跑一次。

第三步：测内存占用。

在并发峰值时看 free 和进程 RSS。

三步做完得到三个数：平均耗时、拐点并发、单请求内存。而这三个数就能反推「这台机器能扛多少」。而这个结论比任何「4 核能扛多少」的通用说法都可靠——因为它是你自己业务的数。

判断方法：三步按顺序做，每步记一个数。

而<'sixtynet'+'> 那种大端口产品，在「带宽是不是瓶颈」这一项也要单独测——否则测出来的是带宽上限而不是并发上限。

再看一个「测试数据」的注意点。

要测「最重的那个页面」,不是首页。

因为「平均」会掩盖「最慢」。

还有一条：「测试」要在「接近真实」的数据量下跑。

空数据库的测试结果没有意义。

再给一个「从业务倒推」的例子。

目标：日活 5000，每人十次访问，集中在四小时内。

总请求：5 万次，四小时 = 14400 秒，平均每秒约 3.5 次。

峰值按五倍算：每秒 18 次。

每次 100ms，则需要并发 1.8，取整为 2。

这个算例的有意思之处在于：算下来只需要「2 个并发」。而很多人一开始就买「8 核 16G」,原因是「不知道该怎么算」。所以「先算再买」这件事,常常能把预算砍掉一大半。而这个算术二十分钟就能做完。

判断方法：日请求数 ÷ 集中时段秒数 × 峰值系数 ÷ 每并发能力。

得到的就是所需并发。

而<'云途'+'> 那种 22 元档位,对「每秒十几请求」的业务完全够用。

再看一个「增长」的预留。

按「一年后的量」买,而不是「现在的量」。

所以「留一倍余量」是合理做法。

还有一条：「峰值系数」要按业务类型定。

「促销类」业务可能是二十倍。

还有一个「静态与动态」的比例。

静态请求几乎不耗 CPU,只耗带宽。

而动态请求才是「并发」的主体。

所以算并发时要把「静态请求」剔出去——因为它们可以靠 CDN 或缓存解决,不需要机器扛。而这一点在「网页站」上能让计算量降一个数量级。所以第一步应该是「把请求分成静态和动态两类」,再算动态那部分。

判断方法：看日志里「静态后缀」占比。

占比高,就该先上 CDN。

而<'spartanhost'+'> 那种大端口产品,即使静态走源站也扛得住。

再看一个「API 与页面」的区别。

API 返回小、耗 CPU；页面返回大、耗带宽。

所以两者的瓶颈不在同一处。

还有一条：「首屏」和「后续请求」的比例也要算。

因为一次页面加载可能产生几十个请求。

再说一个「数据库先满」的情况。

应用并发涨了,但数据库连接池先耗尽。

而表现是「应用没满、数据库排队」。

所以「加应用机器」在这一步完全无效——因为瓶颈在数据库。而正确做法是「加缓存」「读写分离」「优化慢查询」。而这一点常被误判成「应用不够强」,于是不断加应用机器,数据库越来越挤。

判断方法：看数据库的「活跃连接数」和「慢查询数」。

活跃连接接近上限,说明数据库先满。

而<'zji'+'> 那种 16G 整机,适合把「数据库和应用」都放下——但要注意隔离。

再看一个「缓存」的定位。

缓存是为了「减少数据库请求」。

所以「缓存命中率」比「缓存容量」重要，命中率不到七成基本白上。

还有一条：「连接池」不要开满。

留给运维工具几个连接。

补一个「弹性扩容」的做法。

固定配置扛不住突发,但临时升配可以。

而「升配」通常比「加机器」快。

所以「平时低配 + 活动前临时升配」这个组合,成本远低于「常备高配」。而前提是「升配不需要停机」。所以选型时要问「能否在线升配」——这一条比「最高配到多少」更实用。

判断方法：问「升配要不要重启」。

不要,就能弹性用。

而<'rabisu'+'> 那种多档位产品,升配的颗粒度细,适合弹性策略。

再看一个「降配」的代价。

降配往往要重建。

所以「升容易降难」是常见情况，规划时要留余地。

还有一条：「临时升配」要提前操作。

活动当天才升,可能排不上。

最后补一个「成本对照」。

「加机器」和「优化耗时」两条路的成本差可能是十倍。

而「优化」的成本主要是「时间」而不是「钱」，但需要有人会做。

而<'zji'+'> 那种整机产品,是「优化做完还不够」时的兜底。

再有：「先优化后加机器」这个顺序,能省下大部分预算。

而反过来做,往往是「买了大机器还是慢」。

再补一句关于「实测」的价值。

实测能发现「估算完全没想到的瓶颈」。

而这些瓶颈往往不在「三个数」里，尤其不在参数表上。

所以「先测一次」比「先算一遍」更有信息量，也更省时间。

六、估算和实测差在哪

三个偏差，每个都让「估算」偏乐观。

偏差一：真实流量不均匀（峰值是均值的五到十倍）。

偏差二：真实数据量更大（查询更慢）。

偏差三：真实并发不是「均匀铺开」而是「集中打一个点」。

三个偏差的共同点是「估算用的是平均值，实际面对的是峰值」。所以「估算结果除以三」才是可用的容量。而这一点正是「为什么按估算买机器总是紧张」的直接答案。所以保守系数不是「保险」，是「必须」，而且三折只是起点。

判断方法：估算值打三折作为「可持续容量」。

而<'云途'+'> 那种档位密的商家，「先买小再升配」比「一次买足」更划算。

最后回到开头：「能扛多少」这个问题，答案不在参数表里。

而在三个自己测出来的数里：单请求耗时、拐点并发、每请求内存。三个数十分钟能测出，而它们比任何「4 核 8G」的说法都更接近真实,也更能指导下次该买什么。

本文讨论服务端并发能力的估算与实测方法，不针对任何具体商家，也不对任何产品的承载能力作承诺或评价。文中提到的三个数、四个上限、三步实测法与三折保守系数均为通用方法论；实际承载能力取决于应用实现、数据库性能、外部依赖、测试数据量与访问分布，同一配置在不同应用上可能相差一个量级。文中所有数字（如「20 到 500ms」「1 到 50MB」「除以三」）均为经验参考值，非精确基准或行业标准。本文不构成任何性能承诺或购买建议，亦不代表本站立场，也不代表对任何具体产品的推荐。因依据估算结果作出购买决定所产生的直接或间接损失，作者及本站不承担任何责任。