精华内容
下载资源
问答
  • 性能指标之资源指标-磁盘-关注指标

    千次阅读 2017-05-04 11:01:18
    对于业务服务器的用户来说,看到的是文件系统或裸设备,从文件系统到物理磁盘大概是下图的样子。 业务服务器的操作系统作为存储的用户只能看到disk(存储层面的LUN),...并且逐步排查到磁盘时,才重点关注磁盘

    对于业务服务器的用户来说,看到的是文件系统或裸设备,从文件系统到物理磁盘大概是下图的样子。

    业务服务器的操作系统作为存储的用户只能看到disk(存储层面的LUN),而存储管理员才知道存储内部的具体RAID方式、条带化方式等等,在关注系统性能的活动(性能测试、性能调优)中,一般很少直接关注磁盘IO的指标,而是遇到性能问题(比如业务的响应时间非常慢),并且逐步排查到磁盘时,才重点关注磁盘IO的性能指标。这是因为,磁盘IO的性能的确是不好拿一个指标说清楚的事。

    当磁盘IO有性能问题,需要分析IOPS、MBPS、服务时间、平均每次写入的block大小、队列等待时间等指标,分析IO路径、驱动、光纤卡、光纤交换机、后台存储的规划、硬盘域和存储池划分、thin LUN还是thick LUN、存储的缓存设置、IO的Qos、磁盘类型、存储接口模块数量、RAID划分、是否配置快照、克隆、远程复制等增值功能、存储控制器的CPU利用率,甚至数据在盘片的中心还是边缘等等。

    本节并不主要从存储的角度介绍,而是从存储的用户(业务服务器的操作系统)的角度介绍磁盘IO的性能指标,以及相关分析。

    主要关注指标

    虽然每类物理资源都有N个性能指标来体现,但CPU、内存资源最主要的指标只有一个,即利用率,但磁盘IO的主要指标却有三个(IOPS、带宽、响应时间)。这是因为存储的能力会根据IO模型的不同而差异较大,IO模型可以理解为读IO和写IO的比例、顺序的还是随机的、每个IO的大小等等。例如:当测试IOPS最大能力的时候,采用随机小IO进行测试,此时占用的带宽是非常低的,响应时间也会比顺序的IO要长很多。而测试顺序大IO时,此时带宽占用非常高,但IOPS却很低。

    从业务服务器、存储控制器、前端主机端口、磁盘、LUN、存储池等角度,都有以下三个主要指标,本文重点从业务服务器角度介绍。

    IOPS

    I/O per second,即每秒钟可以处理的I/O个数,用来衡量存储系统的I/O处理能力。在数据库OLTP(Online Transaction Processing)业务场景,通常以IOPS衡量系统的性能。测量存储的最大IOPS往往是以随机读写小IO来评估。

    1. 获取来源

    总IOPS:Nmon DISK_SUMM Sheet:IO/Sec
    每个盘对应的读IOPS :Nmon DISKRIO Sheet
    每个盘对应的写IOPS :Nmon DISKWIO Sheet

    总IOPS:命令行iostat -Dl:tps
    每个盘对应的读IOPS :命令行iostat -Dl:rps
    每个盘对应的写IOPS :命令行iostat -Dl:wps

    2. 适用场景

    对于I/O小于64KB的应用场景,存储性能主要关注IOPS指标。
    OLTP(联机事务处理)系统是大量用户在线进行事务操作的数据库业务的一种应用类型。

    OLTP应用的负载特征如下:
    从数据库角度看:
    – 每个事务的读、写、更改涉及的数据量非常小。
    – 数据库的数据必须是最新的,所以对数据库的可用性要求很高。
    – 同时有很多用户访问。
    – 要求数据库快速响应,通常一个事务需要在几秒内完成。

    从存储角度看:
    – 每个I/O非常小,通常为2KB~8KB。
    – 访问硬盘数据的位置非常随机。
    – 至少30%的数据是随机写操作。
    – REDO日志(重做日志文件)写入非常频繁

    带宽

    每秒钟可以处理的数据量,常以KB/S或MB/s或GB/s为单位,表示为KBPS/MBPS/GBPS,用于衡量存储系统的吞吐量。在数据库OLAP(Online Analytical Processing)业务、媒资业务、视频监控业务等应用场景,通常以带宽衡量系统性能。

    1. 获取来源

    总带宽:Nmon DISK_SUMM Sheet:Disk Read KB/s,Disk Write KB/s
    每个盘对应的读带宽:Nmon DISKREAD Sheet
    每个盘对应的写带宽:Nmon DISKWRITE Sheet

    总带宽:命令行iostat -Dl:bps
    每个盘对应的读带宽:命令行iostat -Dl:bread
    每个盘对应的写带宽:命令行iostat -Dl:bwrtn

    2. 适用场景

    对于I/O大于等于64KB的应用场景,存储性能主要关注带宽指标。
    OLAP业务是用户长时间在线对数据库执行复杂的统计查询操作的一种应用类型。

    OLAP应用的负载特征如下:
    从数据库管理员角度看:
    – 数据修改量小或无数据修改。
    – 数据查询过程复杂。
    – 数据的使用频率逐渐减小。
    – 查询结果以统计值呈现,方便查看。

    从存储采样看:
    – 单个I/O数据量大,通常为64KB~1MB。
    – 读取操作通常顺序读取。
    – 当进行读取操作进行时,写操作的数据存放在临时表空间内。
    – 对在线日志写入少。只有在批量加载数据时,写入操作增多。

    响应时间

    也称为时延或者服务时间,发起I/O请求到I/O处理完成的时间间隔,常以毫秒(ms)为单位。

    1. 获取来源

    每个盘对应的读响应时间:命令行iostat -Dl:read - avg serv,max serv
    每个盘对应的写响应时间:命令行iostat -Dl:write - avg serv,max serv

    2. 最佳实践

    数据库OLTP业务一般时延要求10ms以下,事实上大多数情况下不足1ms;VDI(Virtual Desktop Infrastructure)场景一般时延要求30ms以下;视频点播和视频监控的时延要求随码率的不同而不同。

    从业务系统用户的角度,响应时间是这三个指标中最重要的指标。因为,如果IOPS或带宽达到了存储的瓶颈,那么一定会体现在IO响应时间上。

    其他关注指标

    用户从业务系统经常关注的其他指标有:磁盘繁忙程度、队列满等等,这里简单介绍一下。

    磁盘繁忙程度

    Diskbusy体现了磁盘驱动的利用率,即磁盘驱动有百分之多少时间是活动的。

    1. 获取来源

    Nmon DISKBUSY Sheet
    命令行iostat -Dl:% tm_act

    2. 详细解释

    但这个指标的高低与IOPS、带宽并不是线性关系。例如当diskbusy=80%的时候IOPS=500,当diskbusy=90%的时候IOPS可能可以达到800。

    可以把驱动理解为道路,每个IO的数据块理解为道路上行使的汽车。当道路上没有车的时候,认为是不活动的;当道路上有车的时候,认为是活动的,但有1辆车也是活动,有10辆车也是活动。因此diskbusy并不能作为磁盘IO的重要性能指标。但在日常情况下,可以从这个值的高低对磁盘使用情况有个大概的判断。

    服务队列满

    服务队列每秒变满(磁盘不再接受服务请求)的次数。

    1. 获取来源

    命令行iostat -Dl:sqfull

    2. 详细解释

    通常情况下这个sqfull的值为0,如果经常不为0,可能是IO队列深度太小或者磁盘/存储能力不足。

    queue_depth 是IO队列深度,即AIX 一次可以传送到磁盘设备的命令的数量,把命令放在队列中再传送给磁盘可以提高 I/O 性能。这个属性限制了 AIX 可以传送到设备的最大命令的数量。可以通过命令查看lsattr -El hdiskxxx|grep queue_depth,queue_depth 默认数值为 4,可以调整。但调整queue_depth这种方法对于提高磁盘IO能力来说很有限。

    文件系统使用率

    文件系统和inode的利用率其实已经不在磁盘IO的讨论范围,但仍然属于磁盘的范围,需要业务系统用户关注。

    1. 获取来源

    NMON:JFSFILE SHEET
    命令行df- g

    2. 最佳实践

    当使用率超过80%的时候,系统的性能可能会被拖慢。
    同时,统计业务量与文件系统利用率的增长情况,可以推测该文件系统可以支撑的最大业务量,管理员可以根据日常业务量和文件系统的空间,设定备份删除策略。

    Inode使用率

    Inode:索引节点,它用来存放文件及目录的基本信息,inode数量即文件系统的节点的最大数量。

    Inode使用率容易被忽略。对于一些文件大小很小,文件数量却很大的系统,若采用默认参数生成文件系统,可能导致inode数量不足。当inode使用率达到100%后就不能再创建新的文件或目录。

    1. 获取来源

    NMON:JFSINODE SHEET
    命令行df- g:%Iused

    展开全文
  • 目前重点主要关注慢事务,错误等,后续随着各个测试负责人对性能指标的深入理解,可以提供更加专业的性能分析及优化建议,避免在系统测试后期才发现性能方面的问题。目前对公司使用的性能监控工具进行了如...


        由于一些性能问题在日常的系统功能测试中就能突出表现出来,因此在功能测试过程中就进行应用程序的性能监控也很有必要,要求每一个测试负责人在每次测试报告中(系统测试、回归测试、集成测试等)都添加性能监控结果,目前重点主要关注慢事务,错误等,后续随着各个测试负责人对性能指标的深入理解,可以提供更加专业的性能分析及优化建议,避免在系统测试后期才发现性能方面的问题。

    目前对公司使用的性能监控工具进行了如下梳理:

    展开全文
  • Jmeter压测思路+实操+报告分析

    千次阅读 2019-07-19 11:55:12
    核心思路: 性能测试中不只关注并发数,尤其是单接口性能测试的时候,更多关注吞吐量、响应时间等指标来评估服务端性能。验证服务端最高每秒能正确处理的请求数,以及请求的响应延时情况。 首先明确下并发的概念。在...

    RBI性能测试方法,快速瓶颈识别法。
    RBI强调了80%的性能问题可以通过吞吐量测试来发现,其他20%的性能问题可以通过引入并发用户数等更复杂的场景来发现。

    执行方案
    核心思路: 性能测试中不只关注并发数,尤其是单接口性能测试的时候,更多关注吞吐量、响应时间等指标来评估服务端性能。验证服务端最高每秒能正确处理的请求数,以及请求的响应延时情况。
    首先明确下并发的概念。在性能测试中并发可以理解为同一时刻做不同的事,或同一时刻做同样的事。一般我们在性能测试的时候也是这么去模拟的。那这个同一时刻的并发是很难做到的。要知道我们用来发起压力的测试工具本身要能做到同一时刻发起压力,如果设置线程数过多,负载机本身资源不足会有排队,请求建立和服务端的连接过程会排队,请求数据发送到服务的时候在网络队列上也会排队,请求数据达到服务端,在服务端也会进行排队,所以严格意义上的并发多少用户数等等是比较难做到的。
    为什么要压测
    这个问题问的其实挺没有必要的,做开发的同学应该都很清楚,压测的必要性,压力测试主要目的就是让我们在上线前能够了解到我们系统的承载能力,和当前、未来系统压力的提升情况,能够评估出当前系统的承载情况能不能满足当前和未来一段时间的正常运行。压力测试也让架构师和开发人员能够对自己负责的系统做到心中有数,当有大并发需求的活动或者其他突发事件导致的访问暴增,能够提前做好预估和准备应急预案。

    压测难点
    说了那么多,都是压测的必要性,那么既然要测那么重要,我们每次发版本都做一下压测不就好了,这么说的同学一定是没真正参与过压测的,参与过压测的同学都是谈压测色变,不管是测试人员还是开发人员都很害怕压测。大家为什么这么害怕压测,主要原因主要有下面这些压测的难点导致的:

    1)压测环境难准备

    在日常工作过程中,我们肯定遇到过压测环境难申请的问题,为什么难申请主要是因为压测一般要求环境和生产环境一致,那么就意味着压测机器资源的稀缺,没有哪家公司会长期准备所有系统的压测环境,毕竟成本太高,所以一般公司都是准备一些机器让所有系统共用压测环境,每次一个系统要做压测之前都要把上一个压测系统的数据和应用版本、中间件、数据库停掉或删掉,这是非常浪费时间的工作,所以很多公司现在在压测的环境准备都使用docker来准备环境,只需要定期更新docker image就可以,这就可以做到快速还原环境,需要用的时候直接把被测系统的docker image拉下来就行了,所以压测环境已经不再是我们的问题了。

    2)压测数据难准备

    在压测过程中还有个难点就是压测数据准备,如何能尽量真实的模拟生产的数据,最简单的就是录制一段时间生产的访问报文,然后在用压测环境进行正常回放和倍数回放。录制生产真实报文的工作,目前还没有遇到特别好的工具,大部分公司都是自己写个工具进行网络层面的嗅探,将嗅探到的生产报文再加工成Jmeter或者LoadRunner这些压测工具能够识别的压测脚本。这个工作其实只要搞通了一遍以后也没有那么复杂了。

    3)压测工具使用复杂

    压测工具曾几何时不管是测试人员还是开发人员都觉得很高大上,很难使用和学习,其实这个观念在10年前确实是这样的,但是随着越来越多的开源压测工具的兴起,那些复杂又笨重的商用压测工具渐渐被大家淡忘,现在有很多开源的服务端压测工具,使用起来还是很简单的,而且该有的功能基本都有了,前面废话了那么多,就是要说明压测已经不像以前那么复杂了,现在通过简单的环境配置和工具就可以快速的完成一次压力测试,环境准备这个我帮不了大家,今天文章重点就是介绍下开源压测工具的翘楚“Jmeter”的使用和结果分析,让大家爱上压测。

    压测指标
    压测结果指标基本概念:

    Samples:表示一共发出的请求数
    Average:平均响应时间,默认情况下是单个Request的平均响应时间(ms)
    Error%:测试出现的错误请求数量百分比。若出现错误就要看服务端的日志,配合开发查找定位原因
    Throughput:简称tps,吞吐量,默认情况下表示每秒处理的请求数,也就是指服务器处理能力,tps越高说明服务器处理能力越好
    我们常用的压测指标其实并不多,主要就是用户并发量和tps,一般这两个指标是一起使用的,就是在用户这么大的并发量的前提下tps是每秒多少。这么说有点绕口,举个简单的例子,500个用户同时发起服务请求,服务端能够稳定正确处理的交易数。这里能够稳定正确处理的交易数就是我们常说的tps,也叫做服务处理吞吐量,例子中提到的500个用户同时发起服务请求,“同时发起”也很容易被误解,这里说的500用户同时发起请求是指的是500个用户同一秒钟发起的请求,并不是系统同时只能承载500个在线用户,这两个概念是完全不一样的,在制定指标的时候千万不要搞混,尤其是和业务人员沟通的时候一定要说清楚。一般来说我们会统计一段时间生产环境当前在线用户的会话数和接口当时被调用的次数,做个线性的乘数,通过这个乘数可以根据最后压测出的数据来评估系统大概能够承载的用户数。

    使用Jmeter随时压测
    下面我们就详细介绍下如何使用Jmeter来进行服务端接口压测,Jmeter安装起来非常方便,只需要去官网下载解压直接运行shell就可以了。

    官网下载地址:http://jmeter.apache.org/download_jmeter.cgi

    基本概念
    在介绍如何使用Jmeter之前先介绍下Jmeter里的一些基本概念:

    1)测试计划是使用 JMeter 进行测试的起点,它是其它 JMeter 测试元件的容器。

    2)线程组:代表一定数量的并发用户,它可以用来模拟并发用户发送请求。实际的请求内容在Sampler中定义,它被线程组包含。可以在“测试计划->添加->线程组”来建立它,然后在线程组面板里有几个输入栏:线程数、Ramp-Up Period(in seconds)、循环次数,其中Ramp-Up Period(in seconds)表示在这时间内创建完所有的线程。如有8个线程,Ramp-Up = 200秒,那么线程的启动时间间隔为200/8=25秒,这样的好处是:一开始不会对服务器有太大的负载。线程组是为模拟并发负载而设计。

    3)取样器(Sampler):模拟各种请求。所有实际的测试任务都由取样器承担,存在很多种请求。如:HTTP 、ftp请求等等。

    4)监听器:负责收集测试结果,同时也被告知了结果显示的方式。功能是对取样器的请求结果显示、统计一些数据(吞吐量、KB/S……)等。

    5)逻辑控制器:允许自定义JMeter发送请求的行为逻辑,它与Sampler结合使用可以模拟复杂的请求序列。

    6)断言:用于来判断请求响应的结果是否如用户所期望,是否正确。它可以用来隔离问题域,即在确保功能正确的前提下执行压力测试。这个限制对于有效的测试是非常有用的。

    7)定时器:负责定义请求(线程)之间的延迟间隔,模拟对服务器的连续请求。

    8)配置元件维护Sampler需要的配置信息,并根据实际的需要会修改请求的内容。

    9)前置处理器和后置处理器负责在生成请求之前和之后完成工作。前置处理器常常用来修改请求的设置,后置处理器则常常用来处理响应的数据。

    执行步骤【探索tps模式】
    1,配置线程【线程数配置,需求并发用户在1000,这里线程数可配置100–300,一般来说,tps模式不一定需要高并发,线程数尽量不超过1000】;
    持续时间,时间越长,准确性越高,一般定义为5–30分钟内:300秒–1800秒;
    在这里插入图片描述
    2,配置http或https协议请求
    在这里插入图片描述
    3,配置监听器【1,注意监听器影响性能,尽量少增加监听器;2,察看结果树只用在请求调试,调试通过后,务必删除或屏蔽;】
    测试部 > Jmeter压测思路+实操+报告分析 > image2019-7-19 11:18:45.png
    4,响应断言【形成完整校验,尽量添加;根据实际修改】
    测试部 > Jmeter压测思路+实操+报告分析 > image2019-7-19 11:20:56.png
    何时可以结束压测
    一般来说,主要监控聚合报告中三个指标:
    1,95%line>=3000ms或5000ms;
    90%line、95%line、99%line,性能要求高的情况下,监控99%line,一般使用90%line或95%line都可;
    释义:90%Line不等于:90%用户的平均响应时间
    真正解释:一组n个观测值按数值大小排列如,处于p%位置的值称第p百分位数

    举例说明:
    有10个数:

    1、2、3、4、5、6、7、8、9、10 按由大到小将其排列。

    求它的第90%百分位,也就是第9个数刚好是9 ,那么他的90%Line 就是9

    再来解释90%Line

    一组数由小到大进行排列,找到他的第90%个数(假如是12),那么这个数组中有90%的数将小于等于12
    测试部 > Jmeter压测思路+实操+报告分析 > image2019-7-19 11:27:9.png

    2,error%>=预期范围(一般来说1%左右)
    3,throughput>=预期值【吞吐量一般来说等于tps,jmeter衡量性能重要指标,当不断增加并发线程的情况下,tps恒定一个指标后,出现下降状态,最高的tps则为阈值tps】
    这里可见,单接口吞吐量,95%=363ms,error%<0.70%的情况下,tp在1269左右,性能说明很高了

    测试监控
    1,并发测试监控
    并发测试直接发起指定数量的请求,比如一起发起10万请求看一下系统的处理能力,这个时候如果需要服务器的资源使用信息,就不能使用比如zabbix监控系统了,因为一般处理10万请求,对于我们来说20秒可以处理完毕,但是zabbix数据采集是每分钟一次,这样采集到的数据明显是不准的,这样就需要通过系统自带的监控命令,来实时查询服务器的性能,比如可以通过dstat或者glances等动态监控命令来分析系统的性能。

    2,稳定性测试监控
    稳定性测试就是持续不断模拟指定数量请求,来访问服务器,比如我每秒向测试服务器发起4000请求,持续12小时,来看看服务器会出现什么情况,这个时候就需要用到zabbix来进行监控了,下面是我做性能测试的部分监控接口,包含tomcat每秒请求,服务器入口流量,整个集群每分钟请求的http状态码统计,还有服务器资源使用信息。

    测试报告分析思路:

    1)Error%:确认是否允许错误的发生或者错误率允许在多大的范围内;

    2)Throughput:吞吐量每秒请求的数大于并发数,则可以慢慢的往上面增加;若在压测的机器性能很好的情况下,出现吞吐量小于并发数,说明并发数不能再增加了,可以慢慢的往下减,找到最佳的并发数;

    3)压测结束,登陆相应的web服务器查看CPU等性能指标,进行数据的分析;

    4)最大的tps:不断的增加并发数,加到tps达到一定值开始出现下降,那么那个值就是最大的tps。

    5)最大的并发数:最大的并发数和最大的tps是不同的概率,一般不断增加并发数,达到一个值后,服务器出现请求超时,则可认为该值为最大的并发数。

    6)压测过程出现性能瓶颈,若压力机任务管理器查看到的cpu、网络和cpu都正常,未达到90%以上,则可以说明服务器有问题,压力机没有问题。

    7)影响性能考虑点包括:数据库、应用程序、中间件(tomact、Nginx)、网络和操作系统等方面。

    【友情提示】:
    分布式可能需要注意的事项以及压测可能遇到的问题

    A、若是脚本中设置的并发线程数是100,采用3台slaver机器去施加压力,那么对于服务端来说,此时的并发线程数是300。
    B、为了减少出错的可能性,最好按照如下Jmeter 分布式要求:
    1、各个机器在相同目录下安装相同版本的jdk;
    2、各个机器在相同的目录下安装相同版本的jmeter;
    3、配置/etc/hosts的IP和hostname的映射。
    4、修改各个机器的jmeter的默认内存参数,从512m调整为合适大小。
    5、 对压测中出现的异常或错误,可以尝试自己分析下。Response code: 500通常情况下是服务端出现问题,可以查看服务端的日志,看看是否有异常或错误信息,根据提示信息来定位分析,排查的时候可以根据服务端的业务架构一层层的排查下去,直至找到发生问题的服务。对自己没见过的或不太熟悉的错误信息建议google。 比如:Non HTTP response code: java.net.SocketException这种错误,google一把大致就有些可行的解决方案。[Jmeter-User] JMeter Non HTTP response code: java.net.SocketException。

    下面是我自己的群,大家一起讨论学习,现在人不多,来了就是元老哦哈哈,失效的时候联系我

    在这里插入图片描述

    展开全文
  • 服务端压测怎么做

    千次阅读 2020-09-18 14:04:24
    可能很多QA、RD同学跟我都一样,对服务端压测一直没有系统的认知,印象停留在使用压测工具如Jmeter对单接口发压,调整线程数和循环数来制造不同压力,最后计算一下TPS和成功率等就完事了?网上虽然有不少压测相关的...

    转自:https://www.cnblogs.com/zingphoy/p/12824461.html

    可以很好的套用到自己的项目中

    正文:

    博文的内容并不都是我原创的,行文思路来源于一次内部分享,再结合网上众多参考资料总结出来的,算是一个学习笔记。

    可能很多QA、RD同学跟我都一样,对服务端压测一直没有系统的认知,印象停留在使用压测工具如Jmeter对单接口发压,调整线程数和循环数来制造不同压力,最后计算一下TPS和成功率等就完事了?网上虽然有不少压测相关的文章,但多数是压测工具的入门级使用,有的是压测流程和指标的简单解释,或者就是几个大厂牛逼的全链路压测能力和压测平台的介绍。这些文章要不缺少系统性阐述,要不过于抽象不好理解,对没怎么接触过压测的同学不太友好。

    我裂开了

    本文尝试在QA角度梳理一次完整的压测过程,尝试总结更为普适的压测思路,给大家提供更有意义的参考。


    压测背景

    测试分很多种,网上很多文章[1]会玩弄概念,搬出来3个名词:压力测试(Stress Testing)、性能测试(Performance Testing)、负载测试(Load Testing)。一般情况下并不需要做这么细粒度的概念区分,这3个概念我觉得是没办法完整区分各自边界的,至少在程序逻辑上难以做得到,更多差异只是来自于不同的压测策略,所以尽管忽略这几个概念的区别,都叫它压测或者性能测试即可。

    为什么需要压测

    拿技术人熟知的阿里举例,应该是国内做压测最好的一个大厂。外界熟知的阿里2012双11活动,2012年11月11日零点,阿里各种系统报错、立刻下单报错、购物车支付报错、支付系统报错、购物车的东西丢失,系统显示交易成功率不到50%,产生了大量超卖,给阿里带来很大的损失。那一年的双11后,库存、商品、退款和相应数据库的同学,为了处理超卖导致的问题,没日没夜加了两周的班,同时给了用户不少糟糕购物体验。

    为什么出现这么严重的问题?因为对整个全交易链路上的各个子系统的承受能力不清楚,并且错误预估了可能会达到的流量,也没有完善的预案,兵败如山倒。

    2013年阿里首次提出了全链路压测方案:一方面可让链路的各个系统知道自己的承压极限;另一方面可让各个系统有个明确的优化目标,了解到整个链路的瓶颈并评估资源情况。

    单系统压测与全链路压测

    为什么只做单系统压测还不够呢?

    在活动开始的瞬间,各系统都面临自身服务的巨大的压力,而系统之间是有互相依赖关系的,单机压测没有考虑到依赖环节压力都比较大的情况。一个系统出现故障,故障会在链路流转过程中层层累加,会造成无法评估的影响。

    所以最可靠的方式是完全模拟真实场景来压测,通过线上全链路压测提前发现问题。

    压测流程

    完整的压测流程一般包含下面几个步骤,引用自文末参考资料

    1. 压测目标的制定
    2. 压测链路的梳理
    3. 压测环境的准备
    4. 压测数据的构造
    5. 发压测试
    6. 瓶颈定位及容量微调
    7. 压测总结

    常规压测流程


    压测目标

    压测作用

    • 新服务,无预估目标,需要通过压测得到服务基准数据或找到系统瓶颈进行优化
    • 有明确的压测目标,需要通过压测确定服务的各项指标是否达标
    • 常态化压测,为后期性能优化指导方向或提供参考依据

    压测指标

    列举一些常用指标,并不一定都需要关注,根据业务考虑指标的细化粒度。

    • QPS:Query Per Second,每秒处理的请求个数
    • TPS:Transactions Per Second,每秒处理的事务数,TPS <= QPS
    • RT: Response Time,响应时间,等价于Latency
      RT分平均延时,Pct延时(Percentile分位数)。平均值不能反映服务真实响应延时,实际压测中一般参考Pct90,Pct99等指标
    • CPU使用率:出于节点宕机后负载均衡的考虑,一般 CPU使用率 < 75% 比较合适
    • 内存使用率:内存占用情况,一般观察内存是否有尖刺或泄露
    • Load指标:CPU的负载,不是指CPU的使用率,而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息,表示CPU的负载情况,一般情况下 Load < CPU的核数*2,更多参考链接1链接2
    • 缓存命中率:多少流量能命中缓存层(redis、memcached等)
    • 数据库耗时:数据库就是业务的生命,很多时候业务崩掉是因为数据库挂了
    • 网络带宽:带宽是否瓶颈
    • 接口响应错误率 or 错误日志量

    这里要说明一下QPS和TPS的区别:

    • QPS一般是指一台服务器每秒能够响应的查询次数,或者抽象理解成每秒能应对多少网络流量
    • TPS是指一个完整事务,一个事务可能包含一系列的请求过程。举个🌰,访问一个网页,这是一个TPS,但是访问一个网页可能会对多个服务器发起多次请求,包括文本、js、图片等,这些请求会当做多次QPS计算在内,因为它们都是流量

    性能测试中,平均值的作用是十分有限的,平均值代表前后各有50%的量,对于一个敏感的性能指标,我们取平均值到底意味着什么?是让50%的用户对响应时间happy,但是50%的用户感知到响应延迟?还是说50%的时间系统能保证稳定,而50%的时间系统则是一个不可控状态?

    平均响应时间这种指标,只有在你每次请求的响应时间都是几乎一样的前提下才会有一样。再来个例子,人均财富这个概念有多沙雕相信大家也明白,19年有个很搞笑的新闻——腾讯员工平均月薪七万,明白平均值多不靠谱了吧😂。下图是现实世界中一个系统的响应时间柱状图,RT在前20%的请求数较少,但是因为耗时特别短(拉高了均值可能是命中缓存,也可能是请求的快速失败),而大多数RT是在均值之下,那才是系统的实际性能情况。

    均值并不能反映实际情况,引用自:https://www.dynatrace.com/news/blog/why-averages-suck-and-percentiles-are-great/

    所以说,我们不应看最好的结果,相反地,应该控制最坏的结果,用户用得爽他不保证会传播好口碑,但是用户用到生气他保证变为键盘侠肆意大骂,这也是为什么平均值无法带来足够的参考,因为happy的结果蒙蔽了我们的双眼,平均值在压测中丢失太多信息量。

    总结一下,较为科学的评估方法应该将指标-成功率-流量三者挂钩在一起的:

    xx%的响应在xx毫秒内返回,其中成功率为xx%。

    根据这个方针,可以得到一些测试思路:

    1. 在响应时间的限制下,系统最高的吞吐量(这里不对吞吐量做严格定义,当成是QPS或TPS即可)
    2. 在成功率100%的前提下,不考虑响应时间长短,系统能承受的吞吐量
    3. 容忍一定的失败率和慢响应,系统最高能承受的吞吐量(95%成功率,前95%的请求响应时间为xx毫秒时的最大QPS)
    4. 在上面的场景下还要考虑时间和资源,比如最高吞吐量持续10分钟和持续1小时是不一样的,不同的时间持续长度下,机器资源(cpu、内存、负载、句柄、线程数、IO、带宽)的占用是否合理

    目标预估

    压测开展前是需要有目标的,也就是有期望的性能情况,希望接口或系统能达到的性能预期,没有目的的压测是浪费人力,下面给出几种目标预估的方法。

    历史监控数据

    已经上线并且有历史监控数据的接口,可以查看历史数据,找出峰值QPS和PCT99。🌰 若接口A已经上线并且做了监控,在经过某次大活动或者上线时间足够长后,存量监控数据就可以使用了。

    类比

    新接口或者线上未监控的接口,不存在历史数据,但存在类似功能接口的历史监控数据,可以通过类比得出压测的目标。🌰 假设上一年淘宝双十一下订单接口QPS=x,RT=y,这一年天猫平台整起来了,双十一活动与上年淘宝双十一活动场景类似,也沿用QPS=x,RT=y的目标(例子不严谨,理解即可)。

    估算

    新接口或者线上未监控的接口,不存在历史数据,且不存在类似功能接口的数据可供参数考,此时需要估算峰值,常用方法有8/2原则——一天内80%的请求会在20%的时间内到达。

    top QPS = (总PV * 0.8) / (60 * 60 * 24 * 0.2)

    RT如无特殊要求,一般采用默认值:

    • 单服务单表类,RT<100ms
    • 较复杂接口,RT<300ms
    • 大数据量或调用链较长的接口,RT<1s

    🌰-1 电商秒杀活动,预估同时有1000w人参与,简单起见假设总QPS是1000w。由于前端不同的秒杀倒计时形式使得请求有2s的打散,再加上nginx等webserver做了20%几率拒绝请求的策略,所以下单接口总QPS = 1000w / 2 * (1 - 0.2) = 400w/s,最终压测目标为400w/s的QPS。

    🌰-2 电商全天低价抢购活动,屠龙宝刀,点击就送,一刀99级,emmmmm跑题了。根据8/2原则,预估在午休(12-1)和晚上下班后(7-10)共4h是流量高峰,估算接口峰值QPS = 活动全天接口PV / (4*3600s)。

    其他

    除了前面说到的情况,肯定还有一些我们无法下手的三无接口,无参考、无预估、无历史数据,这时候只能一点一点来,慢慢把压力提上去的同时收集数据,最终得出接口的最优处理能力。

    常见性能折线图


    压测准备

    压测场景

    压测是有目的的压测,也就是说不是随便找些接口发一通压力,而压测全部的接口也是做不到的或者说无意义的,得有压测的优先级,所以梳理压测场景是很重要的。高优场景主要有下面几个:

    1. 高频业务场景(今日头条首页下拉刷新)
    2. 关键业务场景,使用频率低,一旦出问题就很严重(微信账号登录)
    3. 性能高消耗场景(淘宝下单)
    4. 曾经出现过问题的场景

    压测有分单接口压测和场景化压测,前者会简单一些,后者一般是多个接口混合操作以组成一个业务场景,两者在方法上是相通的。

    梳理场景时QA需要与RD对齐,确认不同接口的RD负责人、需要压测的接口、系统性能现状以及压测目标;在确定每个接口的压测目标时,要考虑到压测对象是单实例单机房还是集群;在细节上也要确认是单接口压测还是场景化压测,每个接口的流量占比以及优先级,需不需要发足够的压力来触发系统的自动扩容或降级等更进一步的运维能力。

    压测环境

    在梳理完压测场景后,就要确认压测链路是否完整或符合预期。从一个服务到另一个服务,是不是链路上每一个服务都要压到?下游服务如审计安全等是不是已经考虑到?压测过程中产生的脏数据是否会影响线上数据?可能还要细化到具体下游某个服务不参与压测,如何处理呢?以上种种问题,可能需要推动整个链路相关的业务方进行对应业务改造来适配压测流量,改造完后还要自测验证才能正式开始压测,下面讲一些重点问题,部分内容引用自[文末的参考资料][全链路压测的大概思路]。

    脏数据问题

    • 如果是在独立的一套环境中操作,不存在该问题
    • 影子表:如果是在线上操作,一般将数据写入影子表(与原数据表在schema上一致的不同名表)而非原数据表,实现压测数据与线上数据隔离
    • 白名单:指定测试id或者测试账号,在入库后通过统一id区分压测数据,统一处理
    • 各类存储层的压测改造,包括缓存层、消息队列、离线数据库等隔离问题。常规方法在压测链路中透传压测标记(也叫流量染色,挺形象的),比如json数据中加is_stress标记,存储层根据标记区分压测流量,对压测数据添加指定前后缀再入库等特殊处理

    不参与压测的服务如何处理

    • mock server:通过录制request和response的方式,对业务的代码实现无侵入
    • 服务stub:针对压测流量做处理,类似单测stub,代码stub模拟服务返回response,需要修改代码

    主流的业务架构压测图,引用自:https://lishoubo.github.io/2018/07/15/全链路压测的大概思路/

    可以独立部署一套线下环境进行压测。在不影响线上环境的前提下,确保机房,网络,存储,上下游服务与线上保持一致,部署一套独立的环境进行测试,机器与线上隔离,机器出问题不会影响线上。这种方式压测只是针对较少的几个系统进行,因为很难把整个链路所有系统都独立再部署一套,所以应用范围有限。

    备注:上游、下游如何定义? RFC 2616

    Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream.

    下游的输入来自于上游的输出,假设有服务A、B,A调用了B(或者说A依赖B),那B就是A的上游,A就是B的下游,因为A的输入来自于B的输出(A调用了B,获取B的输出)。

    更简单地理解,越接近用户的东西,越是下游。

    更常见的方法是直接使用线上环境压测,在机器负载低的时间段(如深夜)人工发起或定时发起压测。

    压测监控体系

    确认好压测流程的技术支持和Mock数据的支持后,还要确认压测链路的监控体系是否完整,一来方便在压测过程中及时发现问题,二来是为了积攒历史压测数据,三来顺便确认监控系统本身是否可靠且全部到位。一般监控项包括(也就是压测指标):

    • 核心接口和核心依赖的流量、响应耗时、成功率
    • 消息队列、缓存、数据库
    • 机器物理资源

    压测数据

    压测数据其实没什么神秘的,网上说什么按照业务模型产出数据,表达上做了过度抽象反而不好理解,其实意思就是按照业务核心场景将所需要的数据构造出来。关键是要如何科学地模拟线上数据分布,引用文末参考资料,阿里双十一大促中有如下的业务流量漏斗模型,需要给不同场景科学地分配流量比例,这个比例是分析出来的而不是拍脑袋的。可以想象,阿里大促的流量不可能全部最后都走到付款流程,必然很多流量会在前面的流程就结束了,也就意味着,你把全部压测数据都构造成【走到付款场景】的话,你的压测结果是不准确的。

    阿里大促业务流量漏斗图

    为了更好模拟线上真实的用户使用场景和数据,dump线上数据用来压测是很常见的手段,有两种简单思路:

    • 直接回放提前录制的线上流量到压测链路
    • 将现成流量copy一部分引流到压测链路

    数据dump下来是不能直接用的,一来没加压测标记会污染线上数据,二来涉及用户隐私数据。可以将线上数据作为数据源,经过采集、过滤、脱敏等操作后转变为压测数据,注意点有:

    1. 确保数据已添加压测标记
    2. 账户数据要提前完成登录认证等准备工作
    3. 数据要尽可能跟真实数据保持一致,比如,价格,图片等
    4. 数据是否有不同设备型号等特殊要求
    5. 尽量保持和线上相同缓存的命中率
    6. 其他业务特性上的特殊要求……

    压测过程

    基本思路跟做质量保障是一样的,从细粒度开始慢慢集成到整个大系统,就像单测->接口测试->集成测试,压测也是先从简单的开始,一步一步走向全资源全链路,可以参考过程:单接口单机->单接口1/4资源->场景化1/4资源->全量资源压测->拨测

    单接口单机

    在单核(或物理资源少)机器上部署单个服务,排除外部链路、网络等因素,得出自身服务的单核性能情况(单位QPS/core),后续根据此单核性能指标结合压测目标值进行扩容。另外由于是压的单接口单机,无其他接口请求影响,上下游在足够资源的情况下也不会造成瓶颈,所以能确保服务的性能真实值。

    单接口单机可以在正式开始大规模压测前提前发现问题,方便RD做针对的性能优化并快速检验优化效果。一部分问题会先在单接口单机压测环节中发现,而一些隐藏得更深的问题,需要延后到全链路大流量压测才能暴露。

    单接口1/4资源

    单接口单机压测环节,服务端已经完成了部分性能优化,接下来可以进入单接口1/4资源压测,这样是为了验证在单接口单机压测中得到的单核性能数据,在扩容1/4资源下性能是否会线性增长,是否存在性能损耗以及定位损耗源。

    场景化1/4资源

    单接口压测局限很明显,场景化压测由于引入了上下游服务的其他接口的因素,可以发现单接口压测无法发现的问题,更接近线上用户场景。

    全量资源全链路

    全部资源到位后,预估的线上压力是否能承受,这一步也是内网压测过程的最后一步。

    拨测

    除了做内网压测,还要进行拨测验证用户从客户端到服务端的整个带宽资源是否满足预期,内网压测已经确认了业务性能是否达标,因此拨测可以只选择了一个场景进行验证即可。(简单来说拨测相当于压测cdn,检查各地cdn节点资源是否充足)

    压测策略

    压测过程也要提前规划好,然后加入一定的人工策略调整。阿里大促还会有预热环节,预先跑一部分流量使得该缓存的数据提前缓存起来。正式压测时细分有几种压测策略,引用自文末参考资料

    • 峰值脉冲:流量是逐渐变大的一个小坡,还是骤升后保持高峰
    • 系统摸高:关闭熔断降级限流等fallback功能,提高压力观察系统性能转折点
    • fallback策略验证:开启熔断限流等fallback功能,这些功能是否生效,系统是否还能扛得住
    • 破坏性测试:主要为了验证预案的有效性,类似于容灾演练时的预案执行演练,验证后手抢救方案

    除了关注前面讲到的指标外,还需要关注各机房流量是否均匀(若不均匀要确认负载均衡是否work)。


    压测收尾

    发压环节的结束并不代表压测就到此为止。

    数据清理

    如果使用了影子表,可能收尾工作会简单一些,只需要下掉影子表即可。如果数据直接落到了线上数据库,可能一大堆压测数据要清理,压测时会对数据染色(比如指定测试账号或流量携带压测标记),逐层透传,最后根据标志识别删除。

    常见问题

    举例一些可能会发现的典型问题:

    1. 存在多余的http header,导致额外带宽占用
    2. spin_lock对RT影响大,优化锁的方式
    3. 调整nginx worker数量可提高性能
    4. 不恰当的长链接数
    5. 代码实现上对象没有较好复用
    6. cache命中率不符预期
    7. 业务流程上存在冗余
    8. 缺少一层cache
    9. 响应码or错误码可能要继续规范
    10. 下游服务资源不足(其他监控、存储)
    11. 内部系统对压测的限流,需要变更配置或者协商解除限制

    ……


    压测总结

    给出一个完整的压测过程例子:

    1. 确定本次的压测目标,预估各项指标的达标值
    2. 根据服务接口的优先级和使用场景,确认出需要压测的接口
    3. 梳理压测链路上的服务,确认链路完整性
    4. 针对压测链路设计的服务进行压测改造
    5. 准备压测数据,确认压测策略
    6. 开始压测,监控各项指标,多轮压测检验性能优化效果
    7. 压测环境清理
    8. 压测总结报告输出

    压测最终应该输出一份报告总结,其实也就是把整个压测方案、过程、结论记录下来,写明压测目标、压测接口、压测数据、压测结论,给出发现的问题并提供优化方案。往往在压测报告完成时,性能问题已经基本被解决了,报告的意义在于梳理前面的整个流程,给后续的压测提供经验指导。


    参考资料

    Why Averages Suck and Percentiles are Great

    CoolShell-性能测试怎么做

    全链路压测的大概思路

    独家揭秘 | 阿里怎么做双11全链路压测?

    亲历流量尖峰时刻:一名阿里技术员工的双11十年

    What is Upstream and Downstream in Software Development?

    一个阿里技术男经历的六年“双11”:技术改变阿里

    展开全文
  • 所列的指标,本次测试的要求是验证在30分钟内完成2000次用户登录系统,然后进行考勤业务,最后退出,在业务操作过程中页面的响应时间不超过3秒,并且服务器的CPU使用率、内存使用率分别不超过75%、70%,那么按照所...
  • 转自:https://mp.weixin.qq.com/s/XW9geHZ9odHdI7srDiKBIg 目录 背景 环境检测 压力机及压力工具检测 ...空接口压测检测 聚合报告中 throughput 计算 压测及性能排查方法 ...
  • 统一指标,固定环境,主要关注关键指标的变化 重大活动,业务事件前的摸底测试 着重考察高压力情况下的服务表现 摸高测试,找到性能瓶颈点 为水平扩容提供数据依据(即在当前性能表现下,为了...
  • 电商网站性能压测项目总结分享

    千次阅读 2019-10-08 11:18:18
    1. 项目背景及架构介绍 1.1 背景介绍 被测项目是一个 B2B 类的工业品商城网站,主要分为中文...我们对一个系统进行压测前,需要了解清楚系统架构,这样才能知道后续压测需要关注监控哪些服务器指标。本被测电商系...
  • 对比java实现废话就不多说了,本文分享下博主在5.28大促压测期间解决的一个性能问题,觉得这个还是比较有意思的,值得总结拿出来分享下。博主所服务的部门是作为公共业务平台,公共业务平台支持上层所有业务系统(2C...
  • 压力测试一个重点是如何产生压力,通常可以通过自己编写脚本模拟请求,或者使用成熟的压测工具进行。 压力测试很重要的一点是如何使得模拟压测的数据尽量真实,越接近真实用户越好。 2.根据性能报告定位系统瓶颈...
  • 继上一篇JMeter的基本使用介绍(使用Apache JMeter做压力测试),本文介绍如何做SpringCloud分布式系统的全链路压测。 测试策略 如上图,基本思路是基于月活跃用户确定执行的并发数,然后用工具模拟压力输出报告...
  • Jmeter压测学习记录

    2020-11-02 18:26:16
    最主要关注:异常(请求成功率)、吞吐量(TPS)和请求响应量QPS 例如:设置了100个线程,100次循环,10S内完成请求,异常是0的话,并发数就是100*100/10=1000/S,单个接口吞吐TPS正常情况下等于QPS的 相关信息来源:...
  • SolrQuery性能压测参考

    2016-04-08 14:52:02
    1.与老版对比,重点关注新版的[ 查询 ]性能。 跟***确认了,新版与老版的索引结构、查询逻辑都不一样,但是查询的主要用到的查询字段是一样的,可以通过对比,看新版性能如何。 2.老版页面超时 模拟复杂...
  • 关于这几个词的概念,在CSDN上...先大概介绍下这几个词的概念,再结合jmeter压测数据理解: 一、QPS: Queries Per Second(每秒查询率),每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡...
  • 性能压测中的SLA,你知道吗?

    千次阅读 2019-09-05 16:35:47
    本文是《Performance Test Together》(简称PTT)系列专题分享的第6期,该专题将从性能压测的设计、实现、执行、监控、问题定位和分析、应用场景等多个纬度对性能压测的全过程进行拆解,以帮助大家构建完整的性能...
  • 目前在中通性能测试主要分为线上和线下压测两种方案,在反复实践过程中我们渐渐发现这两种方案都有着各自不足之处,且为压测工作带来了很多不便。以下就线上和线下压测的不足分析,谈谈中通是如何一步步改进压测方案...
  • 全链路压测执行过程中,必不可少,也是最关键的6步: 压测预热、执行控制、场景调整......
  •   一、Aggregate Report 是  JMeter  常用的一个 Listener,中文被翻译为“聚合报告 ...4、缓存洞穿,持续压测/去缓存压测/有缓存压测   转载于:https://www.cnblogs.com/dayiran1222/p/8746096.html
  • 字节跳动全链路压测(Rhino)的实践

    万次阅读 2020-10-12 09:58:18
    1. 背景随着公司业务的不断扩张,用户流量在不断提升,研发体系的规模和复杂性也随之增加。线上服务的稳定性也越来越重要,服务性能问题,以及容量问题也越发明显。因此有必要搭建一个有效压测系统...
  • 只要是软件测试工程师都了解过稳定性测试,但总是会有些忽略的点,现关于稳定性测试需关注的点归纳如下: 软件长时间运行,是否正常运行; 长时间对软件的开启、关闭软件和系统是否正常; 长时间执行某个业务后切换...
  • 依据我们的应用部署架构图,本次压测过程中需要关注 SLB、ECS、RDS 的基础指标(云监控)和压测引擎提供的 RPS、RT、成功率等接口指标。各项监控指标均有平台可以支撑,在此不做赘述。 应用性能场景的实现 性能场景...
  • JMeter实用案例:生成Mockup/Dummy JSON数据压测Restful API 在实际工作中我们经常需要做一些性能测试,过去我基本上使用的都是JMeter,这么多年使用下来的一个感受是:JMeter并不太容易上手,但确实强大灵活,可以...
  • Elasticsearch 压测方案— esrally 简介

    千次阅读 2019-05-31 20:05:32
    然而在引入新的解决方案前,不免要做一番调研和测试,本文便是介绍官方的一个 es 压测工具 esrally,希望能为大家带来帮助。 为什么要压测? 关于压测,我们先来看下百度百科上的一个定义。 压测,即压力测试,...
  • 大促之前全链路压测监控篇大促之前全链路压测监控篇skywalking服务监控skywalking简介配置SkyWalkingArthas服务诊断Arthas是什么Arthas能做什么安装使用线程命令dashboard指令thread相关指令显示线程列表虚拟机命令...
  • 如何压测与调优

    2021-01-22 18:38:51
    如何压测与调优背景介绍压测的作用几个压测指标概念压测指标制定压测环境配置系统架构图机器配置压测过程Jmeter脚本调优过程Mysql调优JVM调优Redis调优Tomcat调优 ...吞吐量(TPS-重点关注):吞吐量是指系统
  • 无效压测的背景一:没有专业的性能测试人员或者团队;二:没有独立的性能测试环境;三:上线前临时开展性能测试,时间仓促,准备仓促;四:功能测试人员经常被拉过来填坑性能测试任务,临时抱佛脚查资料;五:没有...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,477
精华内容 990
关键字:

压测重点关注指标

友情链接: xscjglxt2006.rar