5000字详解性能需求服务器磁盘qps数据量

我刚工作时,和政府部门做了个产品,功能就是个表单录入,录入完保存到系统。拿去给用户演示,一切很完美。

但是当开始试运行时,出现了问题——单据录入完成后,保存无反应。

后来一看是用户在每次会同时录入很多条内容,在保存100条数据要30s才能保存成功。500条数据直接保存失败。

当然,这是我的问题,忽略了对性能的要求。

一般在公司里会有专门的测试人员对系统进行性能测试,而对于性能的标准,具体性能指标多少合适,测试同学是不清楚的。

这个时候就需要产品狗们提出性能要求,给测试同学作参考。

接下来我们说说性能需求咋提以及性能指标。

一、性能需求什么时候提

性能需求属于非功能需求,一般在需求文档内需要有单独模块对性能做说明。

在写需求文档的时候就可以把性能需求一起规定好,在需求评审时也要评审下性能需求,让各方达成一致。

研发同学在做技术设计时考虑进来,避免在项目后期,出现重大性能问题。

测试同学在准备测试用例时,把性能也提前规划进来,提前准备好测试方案。

二、性能需求怎么提

性能需求是指对系统性能进行规范化描述,提出明确、合理的性能指标要求。

主要分为2个方面:

1.系统整体性能需求

主要指标包括

2.不同功能/接口性能需求

由于不同功能、不同接口的使用频率、重要程度不同,我们可以对不同功能、不同接口单独提出性能需求。

可以从下边几个标准来确定需要单独明确的功能/接口

下边我们详细说说性能指标以及性能指标的标准

三、常见的性能指标有哪些

我们一个个看看:

吓人不?

即1s内用户完全可以接受,3s内用户觉得还可以,5s用户就会开始焦躁不安。

当然这只是个通用标准,不是个固定标准。我们在提出需求时,可以结合业务重要性、数据量大小、使用频次来做综合考虑。

举个例子:导出excel报表。对于很多B端产品,这是个刚需、高频的功能。

我们可以这样提出性能要求:

2.并发用户数——笼统也直观的指标

并发用户数的定义是每秒同时向服务器提交请求的用户总数量。

关于并发用户数有2个理解:

对于这2个理解,在性能需求上可以分开提,比如:

有几种并发用户数评估方法,大家可以看下:

1)公式1:

n:平均每天的访问用户数。App可以直接用日活代替。

举个例子:

公式里的n=10w,L=10min,T=12h

C=(10w×10×60)/(12×3600)≈1388人/秒

峰值C’=1388×3×根号1388≈1500人/秒

提需求时可以以峰值并发用户数为准

2)公式2:

影响因子一般为3

比如App的每天晚上8点-10点用户最活跃,且活跃用户有8w。

8w/2h×3≈33人/秒

3)公式3:

比如1天的PV有100w

先算80%的PV:100w×80%=80w

并发数就是:80w/17280=46人/秒

如果是B端私有化部署的产品,一般使用人数比较固定,我们可以从企业人员数量做评估:用户数量×比例,比例可以视具体情况而定,一般取8%-20%。

当然这些都是评估方法,得出的具体数据量只是做个参考。

3.吞吐量——衡量系统处理能力的重要指标。

吞吐量的量化指标有:TPS(每秒事务数)、QPS(每秒查询数)

TPS:是指事务数/秒。一个事务是指服务器发送请求,服务器做出反应的过程。

整体过程就是:用户做出操作>>请求服务器>>服务器处理>>服务器处理完成返回到用户。

每秒能完成多少个流程就是多少个TPS

QPS:是指每秒查询率。指一台服务器每秒能够响应的查询次数。

QPS基本类似于TPS,不同的是:在完成一个事务时,会存在多次查询服务器,所以应该是TPS≤QPS。

一般的标准有:

4.CPU

CPU指标主要指的CPU利用率。

程序在运行的时候,会使用CPU做处理计算。就会占用CPU的空间,如果占用过多,系统就会出现卡顿、无响应的情况。

CPU标准:

对于web端,一般指服务器的CPU。而对于移动端,常指手机的CPU。

5.内存

内存主要是运行处理CPU发出的指令,在内存里处理完毕后,再反馈给CPU。

在网络上或者硬盘上加载的资源,一定会通过内存交换,可以理解为:页面加载出来的图片、文字会暂时存到内存里的,处理完成后就删掉。

内存和CPU类似,资源都是有限的,如果占用过多,会出现卡顿或闪退的现象。

内存常内存使用率做为指标,一般<70%。

6.磁盘吞吐量

一般用磁盘繁忙率来确定性能,磁盘繁忙率要<70%。

这个指标了解即可。

7.网络吞吐量

是指有每秒有多少兆流量进出,一般情况下不能超过设备最大传输能力的70%。

8.错误率

错误率=(失败事务数/事务总数)*100%。

在一定并发下,循环调用某个接口,会出现接口报错的情况。错误率正常情况下要为0。

在高并发的情况下错误率一般要低于0.6%,就是成功率要高于99.4%。

像CPU、内存、磁盘、网络是指服务器的资源利用率,主要是对公司内部来说。

性能测试的同学对于这些指标的标准都很清楚,对于我们产品,需要明白这些定义与具体标准即可,性能需求提不提问题都不大。

FPS是指每秒显示的帧数,主要用来体现出app的流畅度。

App的FPS一般>24帧/秒,最好是60帧/秒。

FPS的越高并不意味着越流畅,FPS低也不意味着页面卡。

对于游戏类app帧率要求较高,对于非游戏类app,我认为只要能保证没有明显的卡顿现象就可以了。

2.耗电量

在App中,CPU处理、蓝牙、定位、传感器、GPU(图形处理)都会加快耗电量。

性能指标一般就以上这些,大家需要理解下。

五、性能需求达不到怎么办

一般性能测试同学在测试完成后,会给出对应的性能测试报告,我们可以通过解读性能报告的内容来判断是否需要优化性能。

在我的工作经历中,很多时候会出现性能不达标的情况,如果性能需求不满足,我们可以按照以下方式确定:

1.重新分析指标合不合理

一般在评估时会对性能要求过高,需要重新定义性能指标再做判断。

2.判断实际性能与性能需求是否相差太多

如果相差不大,可以先发版,延期处理性能问题。

如果相差太大,不能接受,就要与研发沟通,确定是否有优化方案、优化方案内容、优化是否会导致延期。

如果会引起延期,就要和领导反馈,以及同步各方。

六、如何从产品设计上提高性能

性能问题归根到底是技术问题,而为了达到更好的性能指标,达到最好的用户体验,我们也可以从产品设计上整点花样。

另外对于缓解用户的焦虑感,可以使用有趣、好玩的加载动画,分散用户的注意力。

七、总结

性能需求是个容易忽视,却无比重要的地方。如果你一直忽略性能需求,下次的需求文档里一定要写上。

如果你不提,一上线系统卡成狗,你是产品,就是你的锅。

本文由@王大鹿原创发布于人人都是产品经理。未经许可,禁止转载

THE END
1.后端开发一个接口在并发状况下,平均响应时间多长比较合理总结来说,后端接口在并发状况下的平均响应时间,应该综合考虑代码优化、数据库查询优化、使用缓存以及负载均衡等多方面因素。通过系统地分析和针对性地优化,能够实现在高并发状况下保持较低的响应时间,从而提供更加流畅的用户体验。 相关问答FAQs: Q1:如何确定后端接口在并发情况下的平均响应时间是否合理? https://docs.pingcode.com/ask/161336.html
2.java平均响应时长计算平均响应时间多少合适Summary是按整个场景的时间来做平均的,最大最小值,也是从整个场景中取出来的。 (1)平均响应时间:事物全部响应时间做平均计算 (2)90%响应时间:将事物全部响应时间进行排序,然后求90%数据中的最大值,即是说事务所有运行次数中,90%落在这个时间内,10%在这个时间之外, https://blog.51cto.com/u_12192/9475309
3.性能测试度量指标(7)资源占用率在性能测试实践中,为了使响应时间更具代表性,响应时间通常是指事务的平均响应时间ART 在实践中要注意,不同行业、不同业务可接受的响应时间是不同的。一般情况下,对于在线实时交易,可接受的响应时间参考如下。 ?互联网企业:500毫秒以下,例如淘宝业务为10毫秒左右。 https://blog.csdn.net/seanyang_/article/details/132841999
4.显示器响应时间是什么显示器响应时间多少够用详解显示器厂商标识的响应时间大多数为典型最高值,全程平均响应时间更考验显示器厂商的技术 响应时间为“上升 时间”和“下降时间”两部份,而通常谈到的响应时间是指两者之和。而所谓的灰阶响应时间,就是相对早期的黑白响应时间而定义的,因为显示器显示的图像极少 出现全黑全白转换,显然不够合理,灰阶响应时间显然更能反映https://g.pconline.com.cn/x/1000/10004535.html
5.如何找到并发数平均响应时间tps的最佳平衡点?讲明白不能只追求并发数大,而忽略tps,所以,这是一个多指标性能需求,假设是这样的:要求响应时间1秒以内,并发数要尽可能的多,tps要尽可能的大。(基础篇中提到的拐点) 是不是依旧有点懵逼?先画一个简单的示意图,方便大家理解(随手画的,大家能理解就ok): https://www.cnblogs.com/jiangmingbai/p/12768477.html