峰值 5000 并发量的服务器需要什么配置比较合理？

2 核 8G 单台 4M 带宽就足够了。适当的把文件存储到 oss 。

有 ssl 的话，2 核扛不住

5000 并发看是什么类型的并发 怎么也不能买个 2 核这种腊鸡配置吧 比如阿里云活动价入手的服务器 买的时候配置买低了的话 提升配置是挺贵的

@jackrelative 你确定这个配置 抗 5000 QPS???

@defunct9 压测经验 ssl 解析 直接 QPS 降一半应该不夸张

@zhuzhibin 非常确定。省点，2 核 4G 都可以。

都这个并发了，必然是不差钱，省那俩钱干啥，尽量配好点，别抠抠搜搜的。。

先给我解释下并发的意思，楼上那么多都是把并发当成每天总访问理解的。真的 5000 并发早就不是单机能承载的了

峰值五千日火的多少？还单机部署，至于这么抠门吗？

并发。也不说清楚怎么样的并发。简单东西。单机 2 核几 w 都可以呢。手动斜眼

这东西还是得看业务场景，如果就是简单的本机应用，最多加个本机 Redis 这种，QPS 5000 的话，2h4g 基本上够用，前提是得用点轻量级的服务端程序，比如 OpenResty 这种，不能用太臃肿的大型程序和框架。

和买 LV 坐公交还是地铁一样无聊的问题

5000 得覆盖千万量级的用户了吧，这种公司堆设备应该都不眨眼了吧，哈哈

并发不是 qps 吗？ 1s 5000 次访问，恐怕单机都不一定够吧？

除非你就是单纯的 hello word 这种静态页面那就当我没说

纯静态页面 2c4g 也不一定够

我们最近压测了下自己的服务器 2 台 4 核 16g 的服务器。在 800 并发下 简单查询接口的响应时间大概在 1s，复杂点的在 3s 左右。楼主可以参考下，楼上说的 2c 4g 在纯静态 的情况下可能还行，已加上数据库和业务逻辑，基本上就挂。再说楼主都到 5000 并发了。业务比较大了，在考虑配置的时候，不能简单的考虑是否可用，还得考虑用户使用体验，所有这个就不要抠了，尽量多做些冗余，提升扩展性

5000 并发很夸张了，等同于一个大型互联网公司某些接口的并发量了

@jackrelative #1 原文：“2 核 8G 单台 4M 带宽就足够了。适当的把文件存储到 oss 。”
======
回复：#1 5k QPS，双核的话意味着每次请求都在 0.6ms 左右，稍微有一点点抖动就得跪。

上家公司峰值 qps 也差不多 5000，后端用了 100 多台技术，我觉得你这单机有点

@sadfQED2 100 多台机器

@jackrelative 你这个有点

抛开需求说并发，没有多大意义，楼主可以把具体的场景发出来

如果是读个 redis 就返回，单机 5000qps 不难。如果是挖一个比特币，给你 100 台机器，qps 做到 1 都不可能

好多人搞不清概念

@jackrelative 5000qps 你搞单机 2c8g，静态页面都一定扛得住。
宽带算一算 4m 分给 5000 每个人分多少

并发啥时候和 QPS 是一回事了？

@AngryPanda 我每秒能够同时响应以及处理 5000 次请求 不合格吗 老哥？狗头

@jackrelative 但凡有点业务 如果扛得住 我当场把我显示器吃掉

@AngryPanda 学习一下，请问要弄清楚这个的话，这个职位叫什么？软件测试工程师？具体需要掌握哪些方面知识？

5000 并发不是 5000qps
如果真是 5000 并发，还差这点钱？直接堆几台顶配

一楼应该不知道 5000 并发是什么意思。

@brendanliu @sagaxu #22 #23 描述的很清楚了，那么到底如何评估呢？开机器进行压测。

你光说峰值 5000 并发量这个没有什么意义，这个真不能象某些人上来就 2 核 4G 拍脑袋瞎说，而且数据库和文件服务器都没有独立部署，不然就不会有压测这个事儿了。
数据库进行复杂查询对 CPU，内存，磁盘占用都非常高，一个线程的业务就可能瞬间就把服务器负载彪到 50%以上。
所以按我的经验来说来数据库操作的业务峰值 5000 都要上分布式系统，数据库和文件服务器都要单位部署，前级需要进行负载均衡了。

别动不动 几千几万的并发，OK ？

只处理过几十并发的不敢发出任何声响

取决于你的应用性能。

应用写的好，且 IO 不密集，4C16G 轻松 handle

你要是应用写的性能渣，那就没救

线上服务十几并发双 2C4G 的瑟瑟发抖

qps
qps 的话 扛不住

有那么大流量尽量用好点的机器吧 影响客户体验都跑了就得不偿失了

@jackrelative 兄弟..你算一下你的带宽..够 5000 人同时访问?

@youxiachai
我做的 IM 类和游戏类的产品，单服压力测试标准都是奔着 1 万的实时在线人数做的。生产环境，单服同时在线有 1.2 万的记录，服务器是 2 核 4G 的。你们的产品是做的淘宝么？

首先找个人来科普下并发的定义，然后再讨论。

@youxiachai 如果不是高频的 http 接口，4M 带宽并没有问题。http 业务较多，proxy 多加两个节点，proxy 节点很便宜。

现在配置都是弹性的，我觉得可以先按一楼的买低一点的配置，然后如果不够再加配置加宽带吧。够不够用取决于 APP 的类型。

@optional 请注意，我说了把文件服务放到 oss 。

HTTP 谈并发意义不大，QPS 才是真理

IM 和游戏类的谈并发意义更大一点。

不谈业务就说并发就是耍流氓

@zhuzhibin 游戏类业务服 2 核 4G+db/redis 单独部署，实时在线的有 1.2 万的记录，cpu 占用 70%左右，mem 占用 60%。社交 im 类产品我保守估计还能翻一倍，2 核 4G 单服至少负载 2 万实时在线。鹅厂某业务部门的标准，1 核 2G 大概就需要做到一万 qps 。你是不是要吃显示器？

@jackrelative ，这就是鹅厂吗？ 1C 2G 要做到 1W QPS，爱了爱了

@jackrelative 0 不说跑游戏还以为跑 hello world 呢

@youxiachai 每个在线用户按一秒钟 1 个请求计算，每个请求 46 字节 tcp 固定开销，业务数据上下行都以 100 字节计算。每个用户一秒钟带宽消耗 146 字节。4MB （云服务带宽是字节为单位，不是比特）够多少人，你自己算。

5000 并发 缺那点服务器钱？ 造成服务不稳定后果更严重吧

@jackrelative 你一个接口响应只消耗 146 字节?5000 并发的公司，会少这几 W 块钱的服务器费用?

@whyiyhw 你想多少字节？超 100 字节都属于比较大的包了。

@jackrelative +1

@whyiyhw pb，一个接口以 5 个 int32 字段，5 个 string，每个 string10 字节计算。字段间隔符为 1 字节。5*4+4*1+5*10+5*1，仅仅 79 字节。

@jackrelative
裸的服务简单返回接口 100 byte 够用了，一般情况下不够
毕竟还有流量染色信息，各种 header，tracing
正常情况下的 RPC 接口几 K 很正常，我们这边还有很多几百 k 甚至上 m 的 response

@jackrelative 也许你的业务场景下可以优化到 79 字节没问题，但你请看看主题， 回复前需要用到的资源前，先把一长串限制条件带上，谢谢！

@jackrelative 游戏的话交互基本要放在内存里了，和普通的互联网业务是不太像的。游戏的资源消耗除了 cpu 就在打包解包网络传输上了，而互联网业务估计要各种 rpc，逻辑上跳的很厉害，也很难测量 qps 。

混合部署的话 cpu,io 瓶颈应该会很严重
阿里云有按时收费的实例，可以测试一下

@youxiachai 大哥我错了......层次比较低..接触的数据都是以 K 为单位..让大哥见笑了...

跳蚤可以跳自己身高的 500 倍 蚂蚁可以举 600 倍体重 所以跳蚤 蚂蚁是力气最大的生物？

5000 qps 看干了啥，返回个 hello world 和做一个转账时 2 回事， 支付宝双 11 峰值 25w 笔 而已。你准备用几台主机搭一个支付宝？

峰值 5K，拿峰值说什么事哦，先看看日均并发多少？说句不好听的，一套打算用一台服务器解决的系统，可能不配峰值 5K 吧
先搞清楚需求吧，要不然讨论来讨论去没啥意思。
我猜峰值 5K 是系统设计指标吧，实际上跑起来可能没 500 。

5000 并发，按照 avg RT 是 200ms 来看，这得 25K QPS 了，

15 秒内 80 并发
一分钟内 400 并发
2 核 8G5M
普通网站没一点问题
主要是加了 CDN，不加 CDN 也没问题

@zhuzhibin #4 QPS 跟并发不是一个东西哦。

QPS （ TPS ）：每秒钟处理 request/事务 数量
并发数：系统同时处理的 request/事务数

QPS （ TPS ）= 并发数 /平均响应时间

@magese 5000 并发的网站非常的 NB 了，一天预计差不多 过亿级别的 PV 了，
如果这样的访问还用单台机，可能要顶不住啊

某些人真的是张口就来，5000 并发知道是什么概念吗？国内一线互联网产品搞个最热的活动峰值也就几万的并发。很多人压根不清楚并发、QPS 、响应时间的关系。楼主的条件只有一个 5000 并发，其他什么也没说，下面就有人敢说配置了。
-----------
并发量描述的是一个请求场景，QPS 代表的是服务端的处理业务能力。请求足够多的话，一般 QPS 会稳定在某个数值，但是并发越高，持续时间越久，平均响应延迟就越大。

先上个天河看看顶不顶得住（狗头）

@zhuzhibin 看了你的回复，想起卢姥爷的梗了 瞬间有点想笑 啊哈哈哈哈

这么大的并发还差服务器的钱钱？

5000 并发 是同一秒内有 5000 访问。

@killerv 看完回帖，还是老哥和我的认知最一致

不知道需要什么样的，我们目前某个业务日常并发 1000，有活动 3000，最高到过 4000，8c16g，目前是 9 个节点。4000qps 的时候，线程池 60%，还有点余量，5000 应该没问题

可以做基准测试，还有后续的性能测试啊。 付费的，免费的测试软件大把。

首先 楼上的 区分下查询业务或者写业务 混合业务啥的 个人做东西不是大厂浪费资源

qps 纯查询的话 1 个没啥问题 4c8g 看情况 2 个 4c8g 稳定也实惠
文件啥的 oss 基本不要钱流量多少一下都免费 cdn 也有部分免流量 redis 啥的 基本都外挂

推荐楼主试下再上 还有正常的并发预估 80%就好了 那有一直高峰不变的

5K 并发已经很高很高了……至少得几十台 16 核的才能扛得住吧。

如果峰很陡峭的话，你就按平均 QPS 设计吧，这个峰咱们用缓冲池把他给削了就成。

这么多流量了，。。。

我司不到 500 并发，也就 600 多台 VM 吧（手动狗头

还要考虑业务压力啊，纯并发 5000 小意思，有业务就不一样了

前面都是大神吗？咋写的代码啊，能教教我吗？ 2 核 4g5000 并发？我们四核 32g 内存服务器压测并发也才不到三千。还是优化后的版本

一群胡说八道的，5000 并发，比 5000qps 大很多，当每个响应时间接近 0 时，5000qps 和 5000 并发接近。如果是算 5000qps，假设你是 c 写的 hello world，算你 1ms 一个请求，1 个核 1 秒钟能提供 1000 个请求的执行时间，这还假设操作系统的调度损耗为 0，你需要 5 个核的服务器。如果是 10ms 一个请求，再 X10 。

@kios 给阿姨来一杯 卡布奇诺

5000 concurrent 如果一个请求耗时 10ms 的话就是 500kqps 。小 VPS 玩个蛋蛋。

@zhuzhibin 哈哈哈哈

@jackrelative 难道不看业务类型？这要是 5000 的交易系统，10 台配置也扛不住

当年我们 500 万日 PV 的服务，压测都是按 30 个并发做的，5000 并发每天至少 8 亿 PV 了吧？牛 X 啊！