服务端性能测试指标及问题排查

一、软件性能测试目标

软件性能测试的目的主要有以下三点:

1. 评价系统当前性能,判断系统是否满足预期的性能需求。

2. 寻找软件系统可能存在的性能问题,定位性能瓶颈并解决问题。

3. 判定软件系统的性能表现,预见系统负载压力,在应用部署之前,评估系统性能。

而对于用户来说,则最关注的是当前系统:

1.是否满足上线性能要求?

2.系统极限承载如何?

3.系统稳定性如何?

二、软件性能测试中关键指标

性能关键指标

资源指标

CPU使用率:指用户进程与系统进程消耗的CPU时间百分比,长时间情况下,一般可接受上限不超过85%。

内存利用率:内存利用率=(1-空闲内存/总内存大小)*100%,一般至少有10%可用内存,内存使用率可接受上限为85%。

磁盘I/O: 磁盘主要用于存取数据,因此当说到IO操作的时候,就会存在两种相对应的操作,存数据的时候对应的是写IO操作,取数据的时候对应的是是读IO操作,一般使用% Disk Time(磁盘用于读写操作所占用的时间百分比)度量磁盘读写性能。

网络带宽:一般使用计数器Bytes Total/sec来度量,Bytes Total/sec表示为发送和接收字节的速率,包括帧字符在内。判断网络连接速度是否是瓶颈,可以用该计数器的值和目前网络的带宽比较。

系统指标:

并发用户数:某一物理时刻同时向系统提交请求的用户数。

在线用户数:某段时间内访问系统的用户数,这些用户并不一定同时向系统提交请求。

平均响应时间:系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。对于系统快速响应类页面,一般响应时间为3秒左右。

事务成功率:性能测试中,定义事务用于度量一个或者多个业务流程的性能指标,如用户登录、保存订单、提交订单操作均可定义为事务,如下图所示:

单位时间内系统可以成功完成多少个定义的事务,在一定程度上反应了系统的处理能力,一般以事务成功率来度量,计算公式如下所示:

超时错误率:主要指事务由于超时或系统内部其它错误导致失败占总事务的比率。

三、性能问题排查的过程

在性能测试过程中,如果出现性能问题,需要测试人员重点关注资源指标和系统指标或者应用性能数据,系统指标是直接观测到的测试数据,比如响应时间过长,事物请求成功率低,超时错误率高等等。当系统指标出现问题时一般会表现在资源指标上,比如cpu高,内存占用多,网络宽带占用高,连接数多等。

当观测到系统资源异常时,比如响应时间长,事物成功率低,超时错误率高等情况时。应该先查应用相关信息,比如日志,应用监控、数据库等等信息,如果这些信息没有问题,再对资源信息进行分析。资源信息分析如下。

CPU问题分析:一般情况下CPU满负荷工作,有时候并不能判定为CPU出现瓶颈,比如Linux总是试图要CPU尽可能的繁忙,使得任务的吞吐量最大化,即CPU尽可能最大化使用。因此,一般判断CPU为瓶颈,主要从两方面:一是CPU空闲持续为0,二是运行队列大于CPU核数(经验值3-4倍),即可判定存在瓶颈,对于CPU高消耗主要由什么引起的,可能是应用程序不合理造成,也可能是硬件资源不足,需要具体问题具体分析,比如问题SQL语句引起,则需要跟踪并优化引起CPU使用过高的SQL语句。

内存问题分析:一般至少有10%可用内存,内存使用率可接受上限为85%。当空闲内存变小时,系统开始频繁地调动磁盘页面文件,空闲内存过小可能是内存不足或内存泄漏引起,需要根据系统实际情况监控分析。

磁盘I/O问题分析:磁盘I/O对于数据库服务器、文件服务器、流媒体服务器系统来说,更容易成为瓶颈,一般从以下几个方面对磁盘I/O进行分析判断:

每磁盘I/O数可用来与磁盘的I/O能力进行对比,如果经过计算得到的每磁盘I/O数超过了磁盘标称的I/O能力,则说明确实存在磁盘的性能瓶颈。

监控磁盘读写,如果磁盘长时间进行大数据量读写操作,且cpu等待超过20%,则说明磁盘I/O存在问题,考虑提高磁盘I/O读写性能。

网络带宽问题分析:判断网络带宽是否是系统运行性能瓶颈的首要条件是网络带宽是否会影响系统交易执行性能。例如:减小网络带宽,并发用户数、响应时间与事务通过率等性能指标是否不能接受;或者增加网络带宽,并发用户数、响应时间与事务通过率等性能指标会得到明显提高。

在实际性能测试中,如果发现始终报连接超时,而实际手工访问可以正常访问,可以通过ping应用服务器IP或网关IP,如果出现网络严重延迟或丢包,则说明网络不稳定,需要检查网络。

通过对资源指标的分析,实际上各个方面都是互相依赖的,不能孤立的单从某个方面进行排查。当一个方面出现性能问题时,往往会引发其他方面的性能问题,例如,大量的磁盘读写势必消耗CPU和IO资源,而内存的不足会导致频繁地进行内存页写入磁盘、磁盘写到内存的操作,造成磁盘IO瓶颈,同时,大量的网络流量也会造成CPU过载,所以,在分析性能问题时,需要从各个方面进行考虑。

软件性能测试是执行、监控、分析、调优不断进行的过程,即监控是为分析提供更多的参考数据,分析是为了进行调优,调优是解决当前系统存在的性能瓶颈,为用户提供更好、更快的客户体验。由于分析、调优需要根据具体问题进行具体分析,本文未做过多说明,只对通用的关键指标进行监控分析,建议在实际工作中可从资源指标与系统指标两个方面,层层检测、步步排查,性能问题就无处藏身,一旦找到出现问题的原因,性能问题也就迎刃而解!

说明:本文部分内容来源于网络。

2019年连续五十一天修心 土司于北京

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,529评论 5 475
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,015评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,409评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,385评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,387评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,466评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,880评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,528评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,727评论 1 295
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,528评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,602评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,302评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,873评论 3 306
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,890评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,132评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,777评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,310评论 2 342

推荐阅读更多精彩内容