如何评估服务器的单机处理能力

    如果评估一台server的单机接入和处理能力? 每秒钟能支持多少并发请求? 当你的leader问你这个问题的时候,你知道怎么应对吗?

    其实这个问题并不难,首先要评估一下这个server的业务模型是什么样的,瓶颈在那儿,一般来说可以分为cpu/内存/网卡,对于下载或流媒体业务来说网卡会成功瓶颈,但对于一般的逻辑server而言,瓶颈一般是cpu,对于一般的cache机机而言,瓶颈一般是内存。

    分析出系统的瓶颈后,再针对瓶颈做的压力测度就可以了。对一般的逻辑server而言,完全可以可以开启若干个client并发请求,并对在不同的每秒并发量时top看系统的性能就可以了。但有时这样做还是不够的,因为模拟的并发量可能并不能准确地评估线上的真实场景,其实,完全可以“灰度放量”一部分用户后,观察系统的负载就可以大致估算出来了。下面给大家看一个例子:

    这台server采用TCP长连接,单个入包在64字节-100字节之间,回包在1000字节左右,内存开销并不高,100个处理进程,每个进程使用4M内存用于处理收、发包的buf,所以内存也不是瓶颈,由于server主要处理业务逻辑,并与后端的存储层交互,所以瓶颈基本在于cpu。下面看一组数据,完全是上线后的真实数据。

1.1500/s

 top - 17:11:25 up 17 days, 22:43,  1 user,  load average: 5.81, 7.32, 8.60 Tasks: 189 total,   8 running, 179 sleeping,   0 stopped,   2 zombie Cpu(s): 30.4%us, 14.9%sy,  0.0%ni, 50.7%id,  0.0%wa,  0.0%hi,  4.0%si,  0.0%st Mem:   8305636k total,  2152036k used,  6153600k free,   425228k buffers Swap:  2104504k total,        0k used,  2104504k free,  1065372k cached

2.1800/s

top - 23:03:05 up 17 days,  4:35,  1 user,  load average: 5.06, 5.28, 5.08 Tasks: 190 total,   6 running, 182 sleeping,   0 stopped,   2 zombie Cpu(s): 29.2%us, 20.1%sy,  0.0%ni, 46.3%id,  0.1%wa,  0.0%hi,  4.2%si,  0.0%st Mem:   8305636k total,  2194556k used,  6111080k free,   429908k buffers Swap:  2104504k total,        0k used,  2104504k free,  1100784k cached

    因为这台server瓶颈不是内存,而是cpu的处理,所以这里看cpu 的idle基本可以评估出系统最大的支持能力。在系统1500/s时有50%的idle,在1800/s时有46%的idle,大概增加300/s cpu会耗大概5%,那基本可以估算出在2400/s时,cpu大概是36%的idle,但系统在负载较高时处理能力会略有下降,所以会低于36%,后来压测了一下,大概是31%idle,这样算下去,系统大概可以支持到3000/s,系统大概有15%的idle,这时系统应该就到满负荷了,所以2800/s应该是系统效率最高的情况。

    这样,就大概评估出了这个系统的接入和处理能力,那么什么时候扩容也就了然于心了。不过有一点需要注意的是,系统在80%负载的时候利用率较高,也比较安全,负载再高的话,业务就有风险了。因为线上的情况多种多样,有时用户行为是不好评估的,这还不算自然增长。昨天我就碰到这样的情况,这就是上面这台server,昨天下午发完一个版本后,发现cpu只有31%的idle,统计了下请求量,2400/s,而前天同一时候,才1200/s-1400/s,为什么会有这么大的增幅呢,肯定是不正常的,看了一下出入包量,也有成倍的增长,难道是用户的行为发了一变化,回想了刚才版本的修改,才想到由于刚才的版本特性,引导用户有问题,导致用户重复操作,产生的滚雪球的效应,不过还好,用户试了几次后发现不行就放弃了,否则server肯定会挂掉的。如果不是之前负载比较低的话,恐怕当时就挂了。有时为了负载均衡和容灾的考虑,也要保证server的冗余。

    其实cpu只是一个标准,评估系统的能力是件需要深入探讨的理题,后面会继续学习并和大家分享!

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏马哥教育

初学者怎么快速掌握Linux运维?

2018年里,Linux运维的职位数量和平均薪资水平仍然持续了去年的强劲增幅,比很多开发岗位涨的都快。从研究机构的数据来看,Linux职位数量和工资水平涨幅均...

48840
来自专栏腾讯移动品质中心TMQ的专栏

走进标准化测试

一、引言 为避免大篇幅的概念介绍,我们直接从项目实践入手,为读者朋友理解标准化测试。在开始,只要理解标准化测试是为了解决项目测试实际问题而产生的测试方案即可。 ...

56370
来自专栏申龙斌的程序人生

零基础学编程025:前24课总结

学会如何学习 2016年12月21日,写下了“零基础学编程”的首篇文章:“零基础学编程”都需要哪些基础?计算机都是从0开始计数,所以就叫第0篇文章了。学习任何技...

350110
来自专栏web前端教室

需求很简单,但代码写的很复杂,这是为啥呢?

勤劳一些的同学应该会经常的去看其它人的代码,经常会发现明明很简单的需求,但代码的具体实现却写的很复杂,这是为啥呢? 面对这种问题,我一般会回复说,“为了应付各种...

21850
来自专栏玉树芝兰

如何高效入门Github?

如今的编程,早已不是单打独斗的模式了。优秀的编程人员,甚至是初学者,都必须学会如何与他人高效协作。Github是编程协作中须要掌握的基础知识。如何尽快入门,少走...

10020
来自专栏牛客网

阿里秋招内推1.2.3面面经(Java后台)

【每日一语】生活并没有那么复杂,要是你喜欢,大可以说我是在探索生命。——《本杰明•巴顿奇事》

13930
来自专栏iOSDevLog

SwiftShot:为增强现实创建游戏

了解Apple如何为WWDC18构建精选演示,并获得使用ARKit,SceneKit和Swift制作自己的多人游戏的技巧。

14030
来自专栏携程技术中心

微分享回放 | 提高系统开发效率的“银弹”——X-series可视化大规模应用开发工具集

作者简介 赫杰辉,携程框架研发部高级研发经理,负责携程DAL组件开发与推广。 在开发一线奋战多年的老兵,热爱中国传统文化和推广开源软件,希望用自己开发的工具为...

36670
来自专栏Java学习网

成为一名更好的程序员:如何阅读源代码

成为一名更好的程序员:如何阅读源代码 阅读源代码有许多益处。你会发现新的架构(construct)和库,与其他的代码维护者产生共鸣,但最重要的是学会如何组织代码...

27870
来自专栏ThoughtWorks

自动化测试框架分类与思考 | 洞见

自动化测试一直是敏捷开发和敏捷测试的重要基石,也是DevOps和CI/CD必不可少的组成部分。由于不同项目的测试需求不同,以及各种不同的限制,导致需要的自动化测...

39740

扫码关注云+社区

领取腾讯云代金券