1. 前言
而本文将介绍，对于软件性能而言，有哪些指标是需要重点关注的，并且这些重点关注的指标又是如何来评估和计算的。
2. 软件性能的关注点
对一个软件做性能测试时，一般需要关注哪些性能项呢？
换个角度来思考，我们在软件设计、部署、使用、维护中一共有哪些角色的参与，然后再考虑这些角色各自关注的性能点是什么？
首先，开发软件的目的是为了让用户使用，我们先站在用户的角度分析一下，用户会关注哪些性能呢。
对于用户来说，当点击一个按钮、链接或发出一条指令开始，到系统把结果以用户感知的形式展现出来为止，这个过程所消耗的时间是用户对这个软件性能的直观印象。也就是我们所说的响应时间，当响应时间较小时，用户体验是很好的。当然用户体验的响应时间包括个人主观因素和客观响应时间，在设计软件时，我们就需要考虑到如何更好地结合这两部分达到用户最佳的体验。如：用户在大数据量查询时，我们可以将先提取出来的数据展示给用户，在用户看的过程中继续进行数据检 索，这时用户并不知道我们后台在做什么。
因此，用户关注的是用户操作后软件的响应时间。
其次，站在管理员或运维的角度考虑，他们一般关注的性能项有什么，通常来说，包括但不限如下一些指标项：
响应时间
服务器资源使用情况是否合理
应用服务器和数据库资源使用是否合理
系统最多支持多少用户访问、系统最大业务处理量是多少
系统性能可能存在的瓶颈在哪里
更换哪些设备可以提高性能
系统能否支持7×24小时的业务访问
再者，站在开发（设计）人员角度去考虑，影响性能的因素，常见有如下一些。
架构设计是否合理
数据库设计是否合理
代码是否存在性能方面的问题
系统中是否有不合理的内存使用方式
系统中是否存在不合理的线程同步方式
系统中是否存在不合理的资源竞争
3. 衡量服务性能的关键指标及评估方法
在如此多的性能指标项中，最为重要的又有哪些？或者是说在衡量服务性能指标时，最常关注的几项性能指标有哪几个：QPS(TPS)、并发数、响应时间。
QPS（TPS）：每秒钟处理request/事务的数量。
并发用户数： 系统同时处理的request/事务的用户数量。
响应时间（Response Time，RT）： 可以理解为服务器处理响应的耗时，一般取平均响应时间。
下面将对QPS(TPS)、并发数、响应时间几项最主要的指标评估方法进行介绍，别急，且往下看。
3.1 并发用户数
1. 提及并发用户数，如何理解什么才算是有效的并发用户？
并发用户：指的是现实系统中操作业务的用户，在性能测试工具中，一般称为虚拟用户数(Virutal User)。
需要注意的是，并发用户跟注册用户、在线用户有很大差别的，并发用户一定会对服务器产生压力的，而在线用户只是 ”挂” 在系统上，对服务器不产生压力，注册用户一般指的是数据库中存在的用户。
并发用户这些用户的最大特征是和服务器会产生交互，这种交互既可以是单向的传输数据，也可以是双向的传送数据。
2.并发用户数常见的评估方法
对于已有系统来说，评估并发用户数，可以从如下几个方面去做数据参考。
1. 系统用户数
2. 在线用户数
3. 并发用户数
一般来说，可选取高峰时刻，在一定时间内使用系统的人数，这些人数可认为是在线用户数，而并发用户数可以取其中8%~15%的比例基数，例如在1个小时内，使用系统的在线用户数为10万，那么取8%~15%（即8000~1.5万）作为并发用户数就基本足够了。
当然，网上也流行另一种并发用户数评估计算方式（可供参考）
它是由几项因素来决定的：
登录系统的用户数量（n），可以理解为平均每天访问用户数。
用户从登录系统到退出系统的时间间隔（L），可以理解为一天内用户从登录到退出系统的时间间隔。
被考察的时间长度（T），可以理解为一天内有多长时间有用户访问系统
利用经验公式估算系统的平均并发用户数和峰值数据，方法可供参考（并不一定准确）：
平均并发用户数为： C = n*L/T
并发用户数峰值: C‘ = C + 3*√C
> 其中√为根号
例如：某系统A，有3000个用户，平均每天大概有400个用户要访问该系统，对于一个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天之内，用户只有在8小时之内会使用该系统。那么，
平均并发用户数为：C = 400*4/8 = 200
并发用户数峰值为：C1 = 200 + 3*√200 = 243
对于新系统来说，如果没有历史数据作参考，建议通过业务部门进行评估。
3.2 响应时间
作为一个用户你可以对吞吐量（QPS、TPS）、并发用户数这些毫不关心，但响应时间却是用户感受系统性能的主要体现。从用户角度来说，软件性能就是软件对用户操作的响应时间。说得更明确一点，对用户来说，当用户单击一个按钮，发出一条指令或在web页面上单击一个链接，从用户单击开始到应用系统把本次操作的结果以用户能察觉的方式展示出来，这个过程所消耗的时间就是用户对软件性能的直观印象。
响应时间既然对用户体验如此重要，那这个时间又是如何评估计算出来的呢？
用一个公式来表示：
响应时间=网络传输时间（请求）+服务器处理时间（一层或是多层）+网络传输时间（响应）+页面前段解析时间
更具体来讲：
响应时间=呈现时间+网络传输时间+系统处理时间
1. 呈现时间
呈现时间主要是指前端的响应时间，这部分时间主要取决于客户端而非服务端。当然，这个呈现时间也不能全怪罪客户端身上！它还和承载它的操作系统有关，以及电脑硬件比如cpu 、内存有关。
2. 网络传输时间
千万不要忽视数据传输时间。试想一下，如果你要寄信给你一个远方的朋友，你想是什么影响你将信息传递给远方的朋友？不是你写信的过程（如果你写的信不像书一样厚的话），也不是你朋友读信的过程，而是送信的过程。
你的带宽是多少？有没有考虑网络延迟？ 互联网是个网，就是算是相同的起点与终点，它有可能走的不同的路线。
这也是为什么我们在一般做性能测试时，一般要强调要在局域网中进行。
3. 系统处理时间
在进行性能测试时，呈现时间和数据传输时间通常都是我们很难控制的，用户使用的电脑千差万别，用户的网络状况也是千差万别。我们唯一能控制的就是将系统的处理请求的时间缩到最短。
如果我们对系统处理进行分解的话，它又是一个非常庞大与复杂的过程。包括了语言、语言框架、中间件，数据库、系统架构以及服务器系统等。
现在的测试工具一般都屏蔽呈现过程，只是模拟多用户并发请求，计算用户得到响应的时间，也不会将服务器的每个响应都向客户端呈现。
对于数据传输的问题，这也是我要强调的性能测试要在局域网中进行，在局域网中一般不会受到数据带宽的限制。所以，可以对数据的传输时间忽略不计。
关于响应时间，要特别说明的一点是，对客户来说，该值是否能够被接受是带有一定的用户主观色彩，也就是说，响应时间的“长”和“短”没有绝对的区别。
在互联网行业对于用户响应时间，有一个普遍的标准：2/5/10秒原则。也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验。在5秒之内响应客户被认为“比较不错”的用户体验，在10秒内给用户响应被认为“糟糕”的用户体验。如果超过10秒还没有得到响应，那么大多用户会认为这次请求是失败的。这里我们还要考虑一个使用频率的因素。如果一个功能，一个月才用上一次，并且要求返回的结果也并非实时的，那么即便慢一些，对于用户来讲，也是可接受的。
3.3 系统吐吞量（QPS\TPS）
系统吞吐量指单位时间内系统处理用户的请求数。从业务角度看，吞吐量可以用：请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量，从网络角度看，吞吐量可以用：字节/秒来衡量
对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力。以不同方式表达的吞吐量可以说明不同层次的问题，例如，以字节数/秒方式可以表示主要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈；已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。
QPS：全名 Queries Per Second，意思是“每秒查询率”，是一台服务器每秒能够响应的查询次数，简单的说，QPS = req/sec = 请求数/秒。比如执行了select操作，相应的QPS就会增加，它代表的是服务器的机器的性能最大吞吐能力。
计算QPS的常用公式：
QPS（TPS）= 并发数/平均响应时间
另外，关于峰值QPS计算方式，一般也可参照2/8原则（供参考，并非一定）：
原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
问：每天300w PV 的在单台机器上，这台机器需要多少QPS？
答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)
TPS即 Transactions Per Second 的缩写，指每秒处理的事务数量。一个事务是指一个客户机向服务器发送请求然后服务器做出回应的过程。
TPS 的过程包括：客户端请求服务端、服务端内部处理、服务端返回客户端。
关于TPS的获取评估方式，对于已有系统来说：可选取高峰时刻，在一定时间内（如3-10分钟），获取系统总业务量，计算单位时间（秒）内完成的笔数，乘以2-5倍作为峰值的TPS，例如峰值3分钟内处理订单18万笔，平均TPS是1000，峰值TPS可以是2000-5000。
对于新系统来说，因为没有历史数据作参考，一般建议通过业务部门进行评估。
QPS和TPS之间的区别，也是很多新手刚接触时容易搞混的，那他们之间到底有什么区别和联系。
一般来说，QPS基本类似于TPS，但不同的是，对于一个页面的一次访问，会形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就会计入“QPS”之中。
如果是对一个接口（单场景）压测，且这个接口内部不会再去请求其它接口，那么TPS=QPS。
例如：访问一个 Index 页面会请求服务器 3 次，包括一次 html，一次 css，一次 js，那么访问这一个页面就会产生一个“TPS”，产生三个“QPS”。
对于衡量单个接口服务的处理能力，一般采用QPS比较多，一般如果衡量事务业务场景的处理能力一般则采用TPS。
注：Jmeter聚合报告中，Throughput是用来衡量吞吐量，通常是由TPS来表示。
4. 小结
一个系统处理性能能力通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等其它消耗导致系统性能下降。
影响系统响应时间由CPU运算、IO、外部系统响应等因素组成。一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等紧密关联，单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。
最后，几点小结和建议：
系统的性能一般由TPS决定，跟并发用户数没有太大直接关系。
系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。
建议性能测试的时候，不要设置过长的思考时间，以最坏的情况下对服务器施压。
一般情况下，大型系统（业务量大、机器多）做压力测试，10000～50000个用户并发，中小型系统做压力测试，5000个用户并发比较常见。
通过系统的监控工具，发现系统的性能瓶颈，通常会发生性能瓶颈的地方有CPU、内存、磁盘、网络、数据库等，而缓存系统容易发生瓶颈的地方是内存，储存型系统则是I/O。
