系​统​吞​吐​量​(​T​P​S​)​、​用​户​并​发​量​、​性​能​测​试、IO负载学习

目录

. 如何评价一个系统的性能
. 系统吞度量
. 网络上下行数据量
. 客户端-服务端TCP同时长连接数量
. 系统性能的指标计算
. 系统IO负载

1. 如何评价一个系统的性能

在文章的开始，我们需要明白几个问题

. 为什么要进行系统性能测试评估
. 什么是性能测试
. 评价一个系统的性能的指标有哪些

0x1: 为什么要进行系统性能测试评估

性能测试的目的是验证系统(或者软件)是否能够达到预期提出的性能指标，同时发现系统中存在的性能瓶颈，最后起到优化系统的目的。包括以下几个方面

. 评估系统的能力
测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策
. 识别体系中的弱点
受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方

. 系统调优
重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能

. 检测系统中的问题
长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突

. 验证稳定性(resilience)可靠性(reliability)
在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法 

0x2: 什么是性能测试

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。从目的来看，性能测试可以分为2种:

//这两者可以结合进行
. 负载测试
通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况
. 压力测试
压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试

0x3: 评价一个系统的性能的指标有哪些

在每种不同的系统架构的实施中，开发人员可能选择不同的性能测试实现方式，造成实际情况纷繁复杂。由于工程和项目的不同，所选用的度量,评估方法也有不同之处。不过仍然有一些通用的步骤帮助我们完成一个性能测试项目。步骤如下

. 制定目标和分析系统
. 选择测试度量的方法
. 学习的相关技术和工具
. 制定评估标准
. 设计测试用例
. 运行测试用例
. 分析测试结果

在本文中，我们将着重了解如下几个维度的指标

. 系统吞度量
. 用户并发量
. 网络上下行数据量
. 客户端-服务端TCP同时长连接数量

2. 系统吞度量

0x1: 系统吞度量要素

一个系统的吞度量(承压能力)与很多因素(指标)紧密相关

.资源利用率
这里所谓的资源是对于系统中的一个抽象的概念，它包括很多方面
    ) reqeust对CPU消耗
    单个reqeust对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高
    ) 内存负载
    系统对系统内存、vm虚拟内存、swap交换区的使用情况
    ) IO负载消耗
    系统在运行中常常会涉及到大量的磁盘读写操作
    磁盘有两个重要的参数: Seek time、 Rotational latency。正常的I/O计数为：/(Seek time+Rotational latency)*0.75
    在此范围内属正常。当达到85％的I/O计数以上时则基本认为已经存在I/O瓶劲。理论情况下，磁盘的随机读计数为125、顺序读计数为225。对于数据文件而言是随机读写，日志文件是顺序读写  

.外部接口
一个系统会将系统内的功能封装成接口(RESTFUL、SOAP)的形式向外部提供，这些外部接口和内部的代码处理逻辑是强关联的

.QPS/TPS(TPSTransactionsPerSecond)
QPS(TPS) = 并发数 / 平均响应时间
每秒钟request/事务数量，它是软件测试结果的测量单位，一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。
事务可以从客户端角度进行定义。如
    ) 一个登录的POST请求可定义为一个事务
    ) 一个文件上传下载的动作也可定义为一个事务
    ) 一组连续的请求操作也可定义一个事务
事务也可从服务器端定义，如
    ) 执行一个数据库事务
    ) 执行一段存储过程
    ) 执行一个服务器请求等。
理解了事务，再理解TPS，TPS需要结合性能测试场景来说明：
    ) 单体测试
        1.1) 本次测试只测登录这一功能，便于分析和寻找瓶颈
        1.2) 也可做并发测试
        TPS=总事务数/总时间(秒)
    ) 混合测试
    多种模块一起进行测试，更符合真实场景，便于对服务器的整体处理能力进行评估
    TPS=单个事务的TPS总和。
大多数情况下，我们使用加权协函数平均方法来计算客户机的得分，测试软件就是利用客户机的这些信息使用加权协函数平均方法来计算服务器端的整体TPS得分

.并发数
系统同时处理的request/事务数

.响应时间
用于测量完成一个特定请求需要花费多少时间。它是一个非常重要的度量值因为它是用户体验的一个指数。尽管这样，你必须确保你理解你测量的是什么
    ) 系统级的反应时间
    ) 组件级的反应时间
它们是完全不同的，因为系统级包括像队列时间这样的变量是差别很大的
值得注意的是，响应时间同时也是不容易测量的度量值，因为它比其它的度量值更容易变化。因此你必需了解反应时间的分布。如果应用对你大部分用户的反应时间是2秒钟，而对10％用户的反应时间却是10秒钟，在这种情况下，你必须
知道这个反应时间的分布，才能精确地评估该问题和解决它。这就要测量它们的反应时间并且得到它们的标准偏差，理想的情况是用一个柱状图把反应时间的分布显示出来

Relevant Link:

http://www.360doc.com/content/10/1022/17/691214_63081271.shtml
http://www.cnblogs.com/argb/p/3448649.html
http://www.ha97.com/5095.html

3. 网络上下行数据量

4. 客户端-服务端TCP同时长连接数量

5. 系统性能的指标计算

0x1: 响应时间: 对请求作出响应所需要的时间

. 网络传输时间: N1+N2+N3+N4
. 应用服务器处理时间: A1+A3
. 数据库服务器处理时间: A2
. 响应时间=N1+N2+N3+N4+A1+A3+A2

0x2: 并发用户数的计算公式

. 系统用户数: 系统额定的用户数量，如一个OA系统，可能使用该系统的用户总数是5000个，那么这个数量，就是系统用户数
. 同时在线用户数: 在一定的时间范围内，最大的同时在线用户数量
. 同时在线用户数 = 每秒请求数RPS(吞吐量) + 并发连接数 + 平均用户思考时间
. 平均并发用户数的计算: C = nL / T
    ) C是平均的并发用户数
    ) n是平均每天访问用户数(login session)
    ) L是一天内用户从登录到退出的平均时间(login session的平均时间)
    ) T是考察时间长度(一天内多长时间有用户使用系统)
. 并发用户数峰值计算: C^约等于C + *根号C
其中C^是并发用户峰值，C是平均并发用户数，该公式遵循泊松分布理论

0x3: 吞吐量的计算公式

. 从业务角度看
吞吐量可以用:
    ) 请求数/秒
    ) 页面数/秒
    ) 人数/天或处理业务数/小时等单位来衡量
. 从网络角度看，吞吐量可以用:
    ) 字节/秒来衡量
. 对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力

以不同方式表达的吞吐量可以说明不同层次的问题，例如

. 以字节数/秒方式可以表示数要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈
. 已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈

0x4: 思考时间的计算公式

Think Time，从业务角度来看，这个时间指用户进行操作时每个请求之间的时间间隔，而在做新能测试时，为了模拟这样的时间间隔，引入了思考时间这个概念，来更加真实的模拟用户的操作。
在吞吐量这个公式中F=VU * R / T说明吞吐量F是VU数量、每个用户发出的请求数R和时间T的函数，而其中的R又可以用时间T和用户思考时间TS来计算：R = T / TS
下面给出一个计算思考时间的一般步骤：

. 首先计算出系统的并发用户数
C=nL / T F=R×C

. 统计出系统平均的吞吐量
F=VU * R / T R×C = VU * R / T

. 统计出平均每个用户发出的请求数量
R=u*C*T/VU

. 根据公式计算出思考时间
TS=T/R

6. IO负载

IO负载在大多数情况下指的是系统对磁盘的访问频率

0x1: 系统级IO监控

iostat -xdm 1

. rrqm/s: 每秒进行 merge 的读操作数目。即 rmerge/s
. wrqm/s: 每秒进行 merge 的写操作数目。即 wmerge/s
. r/s: 每秒完成的读 I/O 设备次数。即 rio/s
. w/s: 每秒完成的写 I/O 设备次数。即 wio/s
. rsec/s: 每秒读扇区数。即 rsect/s
. wsec/s: 每秒写扇区数。即 wsect/s
. rkB/s: 每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节
. wkB/s: 每秒写K字节数。是 wsect/s 的一半
. avgrq-sz: 平均每次设备I/O操作的数据大小(扇区)
. avgqu-sz: 平均I/O队列长度
. await: 平均每次设备I/O操作的等待时间(毫秒)
. svctm: 平均每次设备I/O操作的服务时间(毫秒)
. %util: 一秒中有百分之多少的时间用于 I/O 操作，即被io消耗的cpu百分比

0x2: 进程级IO监控

当前系统哪些进程在占用IO？百分比是多少？占用IO的进程是在读？还是在写？读写量是多少？

iotop、pidstat
block_dump、iodump
iotop.stp

0x3: 业务级IO监控

当前进程某时间内，在业务层面读写了哪些文件(read, write)？读写次数是多少(read、write的调用次数)？读写数据量多少(read、write的byte数)？

ioprofile

0x4: 文件级IO监控

文件级IO监控可以配合/补充"业务级和进程级"IO分析。文件级IO分析，主要针对单个文件。回答当前哪些进程正在对某个文件进行读写操作

lsof、ls /proc/pid/fd、inodewatch.stp

Relevant Link:

http://www.cnblogs.com/peida/archive/2012/12/28/2837345.html
http://itindex.net/detail/46239-linux-io-%E5%88%86%E6%9E%90 

Copyright (c) 2014 LittleHann All rights reserved