性能测试-测试指标
性能测试关注指标

性能测试关注指标⼀、接⼝请求响应指标重点关注以下⼏个指标:需满⾜的并发数TPS(每秒处理事务的能⼒)响应时间(平均响应时间、90%响应时间)错误率性能测试指标通过标准需满⾜的并发数(举例:每天8W⽤户访问,平均在线时长10分钟,1天⽤户24⼩时内使⽤系统)C = 80000 * 0.166/24=553注:0.166为10/60得出C = nL/TC^= C + 3*根号C其中C为平均并发⽤户数,n为login session的数量,L是login session的平均长度,T是值考察的时间长度C^为并发⽤户数峰值需满⾜的TPSTPS = (80000*80%)/(20%*8*60*60)=11/sec 据⼆⼋原则:20%常⽤时间,满⾜80%业务量TPS = n*80%/(20%*活跃时间*60*60)注:活跃时间⼀般为8⼩时响应时间根据在并发情况下的响应时间2/5/10原则,最长不能超过10s 错误率具体系统具体要求,⼀般⼩于万分之⼀缓存命中率具体系统具体要求,⼀般⼤于85%通过CPU占⽤率70% 好,85% 坏,90%+ 很差内存使⽤率⼀般⼩于80%通过⼆、服务器性能指标重点关注以下⼏个指标:线程对cpu占⽤(关注)对内存占⽤(关注)磁盘I/O⽹络情况性能项资源评价CPU占⽤率70%好85%坏90%+很差磁盘I/0<30%好<40%坏<50%+很差⽹络<30%带宽好运⾏队列<2*CPU数量好内存没有页交换好每个CPU每秒10个页交换坏更多的页交换很差更多的页交换很差使⽤命令查看CPU、内存变化情况:top -b -d 1 -p 27854 > 0904logp是进程号,d是1秒收集⼀次,要⽤root⽤户(sudo su -)查看进程号 ps ef |grep acs-job 若重启服务器后,pid会发⽣变化,必须重新获取三、SQLServer数据库查询慢语句(需数据库管理员权限) --总耗CPU最多的前20个SQL:SELECT TOP 20total_worker_time/1000 AS [总消耗CPU 时间(ms)],execution_count [运⾏次数],qs.total_worker_time/qs.execution_count/1000 AS [平均消耗CPU 时间(ms)],last_execution_time AS [最后⼀次执⾏时间],max_worker_time /1000 AS [最⼤执⾏时间(ms)], SUBSTRING(qt.text,qs.statement_start_offset/2+1,(CASE WHEN qs.statement_end_offset = -1THEN DATALENGTH(qt.text)ELSE qs.statement_end_offset END -qs.statement_start_offset)/2 + 1)AS [使⽤CPU的语法], qt.text [完整语法],qt.dbid, dbname=db_name(qt.dbid),qt.objectid,object_name(qt.objectid,qt.dbid) ObjectNameFROM sys.dm_exec_query_stats qs WITH(nolock)CROSS apply sys.dm_exec_sql_text(qs.sql_handle) AS qtWHERE execution_count>1ORDER BY total_worker_time DESC--平均耗CPU最多的前20个SQL:SELECT TOP 20total_worker_time/1000 AS [总消耗CPU 时间(ms)],execution_count [运⾏次数],qs.total_worker_time/qs.execution_count/1000 AS [平均消耗CPU 时间(ms)],last_execution_time AS [最后⼀次执⾏时间],min_worker_time /1000 AS [最⼩执⾏时间(ms)], max_worker_time /1000 AS [最⼤执⾏时间(ms)],SUBSTRING(qt.text,qs.statement_start_offset/2+1,(CASE WHEN qs.statement_end_offset = -1THEN DATALENGTH(qt.text)ELSE qs.statement_end_offset END -qs.statement_start_offset)/2 + 1)AS [使⽤CPU的语法], qt.text [完整语法],qt.dbid, dbname=db_name(qt.dbid),qt.objectid,object_name(qt.objectid,qt.dbid) ObjectNameFROM sys.dm_exec_query_stats qs WITH(nolock)CROSS apply sys.dm_exec_sql_text(qs.sql_handle) AS qtWHERE execution_count>1ORDER BY (qs.total_worker_time/qs.execution_count/1000) DESC四、mysql慢查询相关命令-- 检查慢查询命令是否开启show variables like '%query';-- 查看慢查询命令select * from mysql.slow_log;。
性能测试常见指标

性能测试常见指标最近在学习性能测试的东西,对于⼀些常见性能测试指标做些总结,保存在这⾥⽅便后期查阅,⽂中摘抄⾃某⼤神的博客,⽂末放原⽂链接,有需要的童鞋可以更深⼊了解!什么是性能测试?压⼒测试:强调极端暴⼒稳定性测试:在⼀定压⼒下,长时间运⾏的情况基准测试:在特定条件下的性能测试负载测试:不同负载下的表现容量测试:最优容量概述不同⼈群关注的性能指标各有侧重。
后台服务接⼝的调⽤者⼀般只关⼼吞吐量、响应时间等外部指标。
后台服务的所有者不仅仅关注外部指标,还会关注CPU、内存、负载等内部指标。
拿某打车平台来说,它所关⼼的是智能提⽰的外部指标能不能抗住因⼤波优惠所导致的流量激增。
⽽对于智能提⽰服务的开发、运维、测试⼈员,不仅仅关注外部指标,还会关注CPU、内存、IO等内部指标,以及部署⽅式、服务器软硬件配置等运维相关事项。
外部指标从外部看,性能测试主要关注如下三个指标吞吐量:每秒钟系统能够处理的请求数、任务数。
响应时间:服务处理⼀个请求或⼀个任务的耗时。
错误率:⼀批请求中结果出错的请求所占⽐例。
响应时间的指标取决于具体的服务。
如智能提⽰⼀类的服务,返回的数据有效周期短(⽤户多输⼊⼀个字母就需要重新请求),对实时性要求⽐较⾼,响应时间的上限⼀般在100ms以内。
⽽导航⼀类的服务,由于返回结果的使⽤周期⽐较长(整个导航过程中),响应时间的上限⼀般在2-5s。
对于响应时间的统计,应从均值、.90、.99、分布等多个⾓度统计,⽽不仅仅是给出均值。
下图是响应时间统计的⼀个例⼦吞吐量的指标受到响应时间、服务器软硬件配置、⽹络状态等多⽅⾯因素影响。
吞吐量越⼤,响应时间越长。
服务器硬件配置越⾼,吞吐量越⼤。
⽹络越差,吞吐量越⼩。
在低吞吐量下的响应时间的均值、分布⽐较稳定,不会产⽣太⼤的波动。
在⾼吞吐量下,响应时间会随着吞吐量的增长⽽增长,增长的趋势可能是线性的,也可能接近指数的。
当吞吐量接近系统的峰值时,响应时间会出现激增。
性能测试通常需要监控的指标

性能测试通常需要监控的指标在进行性能测试时,需要监控以下指标以评估系统的性能和效率:1.响应时间:响应时间是衡量系统响应请求的速度。
它是从发送请求到收到相应的时间间隔。
较短的响应时间表示系统运行速度快,用户获得结果的等待时间短。
2.吞吐量:吞吐量是单位时间内系统处理的请求数量。
它表示系统的处理能力,较高的吞吐量意味着系统能够同时处理更多的请求。
3.并发用户数:并发用户数指同时访问系统的用户数量。
它反映了系统能够同时支持的用户数量,较高的并发用户数表示系统能够处理更多的并发请求。
4.CPU使用率:CPU使用率表示当前系统的CPU利用率。
它反映了系统的负载情况,较高的CPU使用率可能导致系统性能下降。
5.内存使用率:内存使用率表示当前系统的内存利用率。
它反映了系统内存的负载情况,较高的内存使用率可能导致系统出现内存不足的情况。
6.网络延迟:网络延迟是从发送请求到接收到响应的时间间隔。
它反映了网络传输的速度和稳定性,较短的网络延迟表示网络传输速度快。
7.数据库响应时间:对于涉及数据库的系统,需要监控数据库的响应时间。
较短的数据库响应时间表示数据库访问效率高。
8.磁盘I/O:磁盘I/O是指磁盘的读写操作。
需要监控磁盘的读写速度和响应时间,较高的磁盘I/O可能影响系统的性能和效率。
9.错误率:错误率表示系统处理请求时出现错误的比率。
较低的错误率表示系统稳定性高,较高的错误率可能表示系统存在问题。
10.带宽利用率:带宽利用率表示当前网络带宽的利用率。
较高的带宽利用率可能导致网络拥堵和传输速度下降。
11.日志记录:性能测试还需要监控系统的日志记录,以便分析和诊断问题。
需要记录系统的运行日志、错误日志和性能日志等。
通过监控这些指标,可以评估系统的性能和效率,并及时发现和解决潜在的性能问题。
性能测试指标

性能测试指标XXX系统性能指标包括以下内容:1、登陆时间≤5秒;2、页面间跳转时间≤3秒;3、精确查询(包括请求服务)响应时间≤1秒;4、模糊查询响应时间≤5秒;5、全文检索、综合查询响应时间≤3秒;6、简单事务处理(包含各类信息录入、修改、删除)≤4秒;7、各类固定统计报表形成时间≤60秒;8、各种比对、分析、布控等复杂事务处理≤120秒;9、支持静态用户(注册用户)在50000以上;10、支持动态用户(在线用户)在1500以上;11、支持并发数300以上;12、系统有效工作时间要求≥99.5%;13、系统故障平均间隔时间:≥30天;14、系统一年的故障停机时间不超过15分钟(停电等不可预测因素除外)。
15、避免出现以下情况:无故退出系统;出现系统不可控的故障提示;因系统故障导致操作系统或机器无法正常工作。
高性能服务接口必须符合平台技术规范,具备一定的性能扩展能力,具备一定的非法应用请求检测能力。
具体性能指标包括:并发响应能力高于500个;数据查询服务中精确查询响应时间小于0.3秒,其他查询响应时间小于0.5秒;小批量数据比对服务响应时间小于0.5秒;服务执行成功率大于99%,服务正常运行率大于99%。
性能测试流程:1.确定系统的并发用户数;2.设计性能测试用例,原则以在高峰时期并发情况较多的操作作为用例基础。
3。
硬件环境准备,这和性能测试的结果有直接关系。
做性能测试的目的之一就是要知道我们的软件系统在特定的硬件环境下最多能承受多少并发用户,当然这要在多次调整各方面性能参数才能定下来。
4。
专业的测试工具嘛做大项目是需要的。
商业的有Loadrunner,QALoad(我常用的压力测试工具),免费的就更多了。
他们一般都可录制测试脚本,但这不算完。
我们需要监控服务器端的性能参数变化,比如Oracle数据库的缓存命中率.....Unix服务器。
windows服务器,应用服务器.....还要将录制脚本填写表单的数据做参数化,即商业测试工具所谓的数据池功能---目的是不要使数据重复(数据表中的主键等限制),而且可以真正的模拟不同用户作不同操作的情况。
性能测试参数指标值方案

性能测试参数指标值方案性能测试是一种测试方法,用于评估系统在不同负载下的性能表现。
在进行性能测试时,需要选择合适的性能测试参数指标值来衡量系统的性能。
本文将介绍一些常见的性能测试参数指标值,并提供一种1200字以上的方案。
一、响应时间(Response Time)响应时间是指用户发起请求后,系统响应请求所需的时间。
响应时间是评估系统性能的重要指标,常用单位为毫秒(ms)。
可以设置不同的负载场景,通过监测系统在不同负载下的响应时间,来评估系统的性能。
二、并发用户数(Concurrency)并发用户数是指系统同时能够处理请求的用户数量。
通过逐渐增加并发用户数,观察系统的性能表现。
常用的并发用户数指标值为100、500、1000等。
三、吞吐量(Throughput)吞吐量是指在单位时间内系统处理的请求数量。
吞吐量一般以每秒请求数(TPS)或每分钟或每小时请求数来衡量。
通过增加负载,观察系统的吞吐量,来评估系统的性能。
通常,可将吞吐量的指标值设置为500、1000、2000等。
四、错误率(Error Rate)错误率是指系统在处理请求时产生错误的比例,常用百分比表示。
通过监测系统的错误率,可以评估系统在不同负载下的稳定性和可靠性。
通常,可将错误率设置为1%、2%或更低值。
五、CPU使用率(CPU Usage)CPU使用率是指系统在处理请求时使用的CPU资源占总CPU资源的比例。
通过监测系统的CPU使用率,可以评估系统的处理能力。
通常,可以将CPU使用率的指标值设置为50%、70%或更高值。
六、内存占用(Memory Consumption)内存占用是指系统在处理请求时使用的内存资源量。
通过监测系统的内存占用情况,可以评估系统的性能和稳定性。
通常,可以将内存占用的指标值设置为500MB、1GB或更高值。
七、网络延迟(Network Latency)网络延迟是指从用户发送请求到服务器响应请求所需的时间。
通过监测系统的网络延迟,可以评估系统的响应速度和网络传输性能。
性能测试常用指标:响应时间,吞吐量,TPS,QPS,并发数,点击数,资源利用率,错误率

性能测试常⽤指标:响应时间,吞吐量,TPS,QPS,并发数,点击数,资源利⽤率,错误率对于性能测试,以上性能指标必须要有清楚的理解,⾃⼰总结如下:1. 响应时间(RT) 是指系统对请求作出响应的时间。
这个指标与⼈对软件性能的主观感受是⼀致的,因为它完整地记录了整个计算机系统处理请求的时间。
由于⼀个系统通常会提供许多功能,⽽不同功能的处理逻辑也千差万别,因⽽不同功能的响应时间也不尽相同,甚⾄同⼀功能在不同输⼊数据的情况下响应时间也不相同。
所以,在讨论⼀个系统的响应时间时,⼈们通常是指该系统所有功能的平均时间或者所有功能的最⼤响应时间。
当然,往往也需要对每个或每组功能讨论其平均响应时间和最⼤响应时间。
对于单机的没有并发操作的应⽤系统⽽⾔,⼈们普遍认为响应时间是⼀个合理且准确的性能指标。
需要指出的是,响应时间的绝对值并不能直接反映软件的性能的⾼低,软件性能的⾼低实际上取决于⽤户对该响应时间的接受程度。
对于⼀个游戏软件来说,响应时间⼩于100毫秒应该是不错的,响应时间在1秒左右可能属于勉强可以接受,如果响应时间达到3秒就完全难以接受了。
⽽对于编译系统来说,完整编译⼀个较⼤规模软件的源代码可能需要⼏⼗分钟甚⾄更长时间,但这些响应时间对于⽤户来说都是可以接受的。
注意: 在性能测试中, 响应时间要做更细致划分2. 吞吐量(Throughput)吞吐量是指系统在单位时间内处理完成的客户端请求的数量, 直接体现软件系统的性能承载能⼒。
这是⽬前最常⽤的性能测试指标。
对于服务器来讲,吞吐量越⾼越好.吞吐量是⼀个很宽泛的概念, 通常情况下,⽤“请求数/秒”或者“页⾯数/秒”来衡量。
体现:1. 业务⾓度: 业务数/⼩时或访问⼈数/天等2. ⽹络流量: 字节数/⼩时或字节数/天等3. 服务器性能处理能⼒(重点): TPS(每秒事务数) 和 QPS(每秒查询数):对于⽆并发的应⽤系统⽽⾔,吞吐量与响应时间成严格的反⽐关系,实际上此时吞吐量就是响应时间的倒数。
性能测试报告里包含哪些关键的性能指标

性能测试报告里包含哪些关键的性能指标我们做性能测试的目标是,在大用户量、数据量的超负荷下,获得服务器运行时的相关数据,从而分析出系统瓶颈,提高系统的稳定性。
而在一份性能测试报告里,会看到以下的这些关键的数据指标:最大并发用户数,HPS(点击率)、事务响应时间、每秒事务数、每秒点击量、吞吐量、CPU使用率、物理内存使用、网络流量使用等。
但性能测试的指标,前后端的性能测试关注点是不一样的。
前端需主要关注的点是:响应时间:用户从客户端发出请求,并得到响应,以及展示出来的整个过程的时间。
加载速度:通俗的理解为页面内容显示的快慢。
流量:所消耗的网络流量。
后端需主要关注的是:响应时间:接口从请求到响应、返回的时间。
并发用户数:同一时间点请求服务器的用户数,支持的最大并发数。
内存占用:也就是内存开销。
吞吐量(TPS):Transaction Per Second, 每秒事务数。
在没有遇到性能瓶颈时:TPS=并发用户数某事务数/响应时间。
错误率:失败的事务数/事务总数。
资源使用率:CPU占用率、内存使用率、磁盘I/O、网络I/O。
系统性能指标、资源性能指标、稳定性指标一、系统性能指标常见的可从如下几类进行参考:响应时间系统处理能力吞吐量并发用户数错误率1、响应时间简称RT,指的是客户发出请求到得到系统响应的整个过程的时间。
也就是用户从客户端发起一个请求开始,到客户端接收到从服务器端返回的响应结束,整个过程所耗费的时间。
直观上看,这个指标与人对软件性能的主观感受是非常一致的,因为它完整地记录了整个计算机系统处理请求的时间。
2、系统处理能力指系统在利用系统硬件平台和软件平台进行信息处理的能力。
系统处理能力通过系统每秒钟能够处理的交易数量来评价,交易有两种理解:一是业务人员角度的一笔业务过程;二是系统角度的一次交易申请和响应过程。
前者称为业务交易过程,后者称为事务(事务是用户其中一步或几步操作的集合)。
两种交易指标都可以评价应用系统的处理能力。
性能测试指标TPS(TransactionperSecond)总结

性能测试指标TPS(TransactionperSecond)总结性能测试指标TPS(Transaction per Second)总结TPS(Transaction per Second)定义: tps是Transaction per Second的缩写,也就是事物数/秒。
它是软件测试结果的测量单位,⼀个事物是指⼀个客户机向服务器发送请求饭后服务器做出反应的过程。
客户机在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使⽤时间和完成的事物数,最终利⽤这些信息来估计得分。
TPS(Transaction per Second)作⽤: 反映了系统在同⼀时间内处理业务的最⼤能⼒,这个数据越⾼,说明处理能⼒越强,描述(看到系统的TPS随着时间的变化逐渐变⼤,⽽在不到多少分钟的时候系统 每秒可以处理多少个事物。
这⾥的最⾼值并不⼀定代表系统的最⼤处理能⼒,TPS会受到负载的影响,也会随着负载增加⽽逐渐增加,当系统进⼊繁忙期后,TPS会有所下降。
) ⽽在⼏分钟以后开始出现少量的失败事物)TPS(Transaction per Second)局限性: 1、tps是从客户端⾓度审视服务器处理能⼒,并不是说TPS可以达到什么程度就能⽀持多少并发(例如:⼀个业务100个交易,另⼀个业务10个交易)。
2、TPS = 脚本运⾏期间所有事物总数 / 脚本运⾏时长,如果使⽤集合点策略,在脚本执⾏前的等待时间过程中,服务器没有处理事务,那么这个时候的TPS和理想中的结果不⼀致。
3、限制TPS的原因:服务器本⾝性能、代码结构、客户端施加的压⼒以及⽹卡等。
TPS(Transaction per Second)与响应时间的关系: 1、TPS和响应时间在理想状态下的额定值。
如果20个⼊⼝,并发数只有10的时候,TPS就是10,⽽响应时间始终都是1,说明并发不够,需要增加并发数达到TPS的峰值。
2、如果增加到100并发,则造成了线程等待,引起平均响应时间从 1 秒变成 3 秒,TPS也从20下降到9;TPS和响应时间都是单独计算出来的,两者不是互相计算出来的。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
1 引言1.1 编写目的本文总结提炼性能测试相关项目实施经验,规范使用性能测试进行性能测试系统技术指标,规范技术测试结果评价,统一性能测试技术测试质量度量。
应用系统技术质量度量指标范围广泛,本文难以涵盖全部。
用常用指标来进行说明,其他未说明指标将在后续测试工作中继续补充和完善本指标体系。
1.2 适用对象和范围本指标适用于使用性能测试进行性能测试项目技术质量评价依据。
预期读者为测试管理人员、测试实施人员、技术支持人员、项目管理人员等系统技术质量相关人员。
2 系统性能指标2.1 业务指标业务指标主要包括并发用户数、响应时间、处理能力,这三个指标有一定的关系的,具体可参照:《并发用户数与TPS关系》2.1.1 交易响应时间2.1.1.1 定义及解释响应时间指用户从客户端发起一个请求开始,到客户端接收到从服务器端返回的响应结束,整个过程所耗费的时间。
在性能检测中一般以测试环境中压力发起端至服务器返回处理结果的时间为计量,单位一般为秒或毫秒,该时间不同于模拟真实环境的用户体验时间。
平均响应时间:指系统稳定运行时间段内,同一交易的平均响应时间。
一般而言,交易响应时间均指平均响应时间。
平均响应时间指标值应根据不同的交易分别设定,一般情况下,分为复杂交易响应时间、简单交易响应时间、特殊交易响应时间。
其中,特殊交易响应时间的设定必须明确该交易在响应时间方面的特殊性。
2.1.1.2 简称Response Time: RT2.1.1.3 标准不同行业不同业务可接受的响应时间是不同的,一般情况,对于在线实时交易:•互联网企业:500毫秒以下,例如淘宝业务10毫秒左右。
•金融企业:1秒以下为佳,部分复杂业务3秒以下。
•保险企业:3秒以下为佳。
•制造业:5秒以下为佳。
对于批量交易:•时间窗口:不同数据量结果是不一样的,大数据量的情况下,2小时内完成。
2.1.2 系统处理能力2.1.2.1 定义及解释系统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。
系统处理能力通过系统每秒钟能够处理的交易数量来评价,交易有两种理解:一是业务人员角度的一笔业务过程;二是系统角度的一次交易申请和响应过程。
前者称为业务交易过程,后者称为事务。
两种交易指标都可以评价应用系统的处理能力。
一般的建议与系统交易日志保持一致,以便于统计业务量或者交易量。
系统处理能力指标是技术测试活动中重要指标。
2.1.2.2 简称一般情况下,用以下几个指标来度量:•HPS(Hits Per Second):每秒点击次数,单位是次/秒。
•TPS(Transaction per Second):系统每秒处理交易数,单位是笔/秒。
•QPS(Query per Second):系统每秒处理查询次数,单位是次/秒。
对于互联网业务中,如果某些业务有且仅有一个请求连接,那么TPS=QPS=HPS,一般情况下用TPS来衡量整个业务流程,用QPS来衡量接口查询次数,用HPS来表示对服务器点击请求。
2.1.2.3 标准无论TPS、QPS、HPS,此指标是衡量系统处理能力非常重要的指标,越大越好,根据经验,一般情况下:•金融行业:1000TPS~9000TPS•保险行业:100TPS~1000TPS•制造行业:10TPS~50TPS•互联网电子商务:10000TPS~100000TPS,例如天猫5万TPS•互联网中型网站:100TPS~500TPS•互联网小型网站: 50TPS~100TPS2.1.3 并发用户数2.1.3.1 定义及解释并发用户数指在同一时刻内,登录系统并进行业务操作的用户数量。
并发用户数对于长连接系统来说最大并发用户数即是系统的并发接入能力。
对于短连接系统而言最大并发用户数并不等于系统的并发接入能力,而是与系统架构、系统处理能力等各种情况相关。
在测试中,采用虚拟用户来模拟现实中用户进行业务操作。
2.1.3.2 简称Virtual User: VU2.1.3.3 标准一般情况下,性能测试是将系统处理能力容量测出来,而不是测试并发用户数,除了服务器长连接可能影响并发用户数外,系统处理能力不受并发用户数影响,可以用最小的用户数将系统处理能力容量测试出来,也可以用更多的用户将系统处理能力容量测试出来。
2.1.4 错误率2.1.4.1 定义及解释错误率指系统在负载情况下,失败交易的概率。
错误率=(失败交易数/交易总数)*100%。
稳定性较好的系统,其错误率应该由超时引起,即为超时率。
2.1.4.2 简称Failure Ratio: FR2.1.4.3 标准不同系统对错误率的要求不同,但一般不超出千分之六,即成功率不低于99.4%2.2 资源指标2.2.1 CPU2.2.1.1 定义及解释中央处理器是一块超大规模的集成电路,是一台计算机的运算核心(Core)和控制核心(Control Unit)。
它的功能主要是解释计算机指令以及处理计算机软件中的数据。
CPU Load: 系统正在干活的多少的度量,队列长度。
系统平均负载。
2.2.1.2 简称Central Processing Unit:CPU2.2.1.3 标准CPU指标主要指的CPU利用率,包括用户态(user)、系统态(sys)、等待态(wait)、空闲态(idle)。
CPU 利用率要低于业界警戒值范围之内,即小于或者等于75%;CPU sys%小于或者等于30%, CPU wait%小于或者等于5%。
单核CPU也需遵循上述指标要求。
CPU Load要小于CPU 核数。
2.2.2 Memory2.2.2.1 定义及解释内存是计算机中重要的部件之一,它是与CPU进行沟通的桥梁。
计算机中所有程序的运行都是在内存中进行的,因此内存的性能对计算机的影响非常大。
2.2.2.2 简称Memory就是内存的简称。
2.2.2.3 标准现代的操作系统为了最大利用内存,在内存中存放了缓存,因此内存利用率100%并不代表内存有瓶颈,衡量系统内有有瓶颈主要靠SWAP(与虚拟内存交换)交换空间利用率,一般情况下,SWAP交换空间利用率要低于70%,太多的交换将会引起系统性能低下。
2.2.3 磁盘吞吐量2.2.3.1 定义及解释磁盘吞吐量是指在无磁盘故障的情况下单位时间内通过磁盘的数据量。
2.2.3.2 简称Disk Throughput.2.2.3.3 标准磁盘指标主要有每秒读写多少兆,磁盘繁忙率,磁盘队列数,平均服务时间,平均等待时间,空间利用率。
其中磁盘繁忙率是直接反映磁盘是否有瓶颈的的重要依据,一般情况下,磁盘繁忙率要低于70%。
2.2.4 网络吞吐量2.2.4.1 定义及解释网络吞吐量是指在无网络故障的情况下单位时间内通过的网络的数据数量。
单位为Byte/s。
网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。
当网络吞吐量指标接近网络设备或链路最大传输能力时,则需要考虑升级网络设备。
2.2.4.2 简称Network Throughput2.2.4.3 标准网络吞吐量指标主要有每秒有多少兆流量进出,一般情况下不能超过设备或链路最大传输能力的70%。
2.2.5 内核参数操作系统内核参数主要包括信号量、进程、文件句柄,一般不要超过设置的参数值即可,具体如下:2.3 中间件指标2.3.1 定义及解释常用的中间件例如Tomcat、Weblogic等指标主要包括JVM, ThreadPool, JDBC,具体如下:2.3.2 标准•当前正在运行的线程数不能超过设定的最大值。
一般情况下系统性能较好的情况下,线程数最小值设置50和最大值设置200比较合适。
•当前运行的JDBC连接数不能超过设定的最大值。
一般情况下系统性能较好的情况下,JDBC最小值设置50和最大值设置200比较合适。
•GC频率不能频繁,特别是FULL GC更不能频繁,一般情况下系统性能较好的情况下,JVM最小堆大小和最大堆大小分别设置1024M比较合适。
2.4 数据库指标2.4.1 定义及解释常用的数据库例如MySQL指标主要包括SQL、吞吐量、缓存命中率、连接数等,具体如下:2.4.2 标准•SQL耗时越小越好,一般情况下微秒级别。
•命中率越高越好,一般情况下不能低于95%。
•锁等待次数越低越好,等待时间越短越好。
2.5 前端指标2.5.1 定义及解释前端指标主要包括页面展示和网络所花的时间,具体如下:2.5.2 标准•页面要尽可能小及压缩。
•页面展示和花费时间越短越好。
2.6 稳定性指标2.6.1 定义及解释最短稳定时间:系统按照最大容量的80%或标准压力(系统的预期日常压力)情况下运行,能够稳定运行的最短时间。
一般来说,对于正常工作日(8小时)运行的系统,至少应该能保证系统稳定运行8小时以上。
对于7*24运行的系统,至少应该能够保证系统稳定运行24小时以上。
如果系统不能稳定的运行,上线后,随着业务量的增长和长时间运行,将会出现性能下降甚至崩溃的风险。
2.6.2 标准•TPS曲线稳定,没有大幅度的波动。
•各项资源指标没有泄露或异常情况。
2.7 批量处理指标2.7.1 定义及解释指批量处理程序单位时间内处理的数据数量。
一般用每秒处理的数据量来衡量。
处理效率是估算批量处理时间窗口最重要的计算指标。
关于批量处理时间窗口,不同系统的批量处理时间窗口在起止时间上可以部分重叠。
另外,同一系统内部,也可能存在多个批量处理过程同时进行,其时间窗口相互叠加。
长时间批量处理将会对联机在线实时交易产生重大的性能影响。
2.7.2 标准•在数据量很大的情况下,批处理时间窗口时间越短越好。
•不能影响实时交易系统性能。
2.8 可扩展性指标2.8.1 定义及解释指应用软件或操作系统以群集方式部署,增加的硬件资源与增加的处理能力之间的关系。
计算公式为:(增加性能/原始性能)/(增加资源/原始资源)*100%。
扩展能力应通过多轮测试获得扩展指标的变化趋势。
一般扩展能力你常好的应用系统,扩展指标应是线性或接近线性的,现在很多大规模的分布式系统的扩展能力非常好。
2.8.2 标准•理想的扩展能力是资源增加几倍,性能就提升几倍。
•扩展能力至少在70%以上。
2.9 可靠性指标2.9.1 双机热备对于将双机热备作为可靠性保障手段的系统,可衡量的指标如下:•节点切换是否成功及其消耗时间•双机切换是否有业务中断•节点回切是否成功及其耗时•双机回切是否有业务中断•节点回切过程中的数据丢失量在进行双机切换的同时,使用压力发生工具模拟实际业务发生情况,对应用保持一定的性能压力,保证测试结果符合生产实际情况。
2.9.2 集群对于使用集群方式的系统,主要通过以下方式考量其集群可靠性:•集群中某个节点出现故障时,系统是否有业务中断情况出现•在集群中新增一个节点时,是否需要重启系统•当故障节点恢复后,加入集群,是否需要重启系统•当故障节点恢复后,加入集群,系统是否有业务中断情况出现•节点切换需要多长时间在验证集群可靠性的同时,需根据具体情况使用压力工具模拟实际业务发生相关情况,对应用保持一定的性能压力,确保测试结果符合生产实际情况。