上周，对性能测试系列专题，在公号内发表了第一篇介绍：【性能系列连载一】开篇：性能测试不可不知的 “干货”，但反响貌似并不太好，但既然此前已答应了部分读者要连载分享性能这块的知识，含着泪也得继续写。
性能测试的基础：就是在确保功能实现正确的前提下，通过合适的性能测试加压方式和策略，并收集考察服务端应用程序的各项性能指标，以及服务器硬件资源的使用情况，来评估是否存在性能问题隐患。
那今天作为性能测试系列的第二篇，主要会为大家介绍在服务端性能测试中，常见的性能指标有哪些。
从性能测试分析度量的度角来看，可以从如下几个维度来收集考察各项性能指标：
下面将从如上这几个维度，分别从各自维度常见指标，以及指标含义、指标行业参考标准等方面进行介绍。
系统性能指标，常见的可从如下几类进行参考：
定义和解释：响应时间，简称 RT。是指系统对请求作出响应的时间，可以理解为是指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。
在性能检测中一般以压力发起端至被压测服务器返回处理结果的时间为计量，单位一般为秒或毫秒，由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。
行业参考标准：
不同行业不同业务可接受的响应时间是不同的，一般情况，对于在线实时交易：
需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。
定义和解释：系统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。系统处理能力通过系统每秒钟能够处理的交易数量来评价，交易有两种理解：一是业务人员角度的一笔业务过程；二是系统角度的一次交易申请和响应过程。前者称为业务交易过程，后者称为事务。两种交易指标都可以评价应用系统的处理能力。
一般情况下，系统处理能力又用以下几个指标来度量：
对于互联网业务中，如果某些业务有且仅有一个请求连接，那么 TPS=QPS=HPS，一般情况下用 TPS 来衡量整个业务流程，用 QPS 来衡量接口查询次数，用 HPS 来表示对服务器点击请求。
行业参考标准：
无论 TPS、QPS、HPS，此指标是衡量系统处理能力非常重要的指标，越大越好，根据经验，一般情况下：
定义和解释：吞吐量是指系统在单位时间内处理请求的数量。
对于单用户的系统，响应时间可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。
而对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是 t，当有你 n 个用户使用时，每个用户看到的响应时间通常并不是 n×t，而往往比 n×t 小很多（当然，在某些特殊情况下也可能比 n×t 大，甚至大很多）。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。
定义和解释：并发用户数指在同一时刻内，登录系统并进行业务操作的用户数量。
并发用户数对于长连接系统来说最大并发用户数即是系统的并发接入能力。对于短连接系统而言最大并发用户数并不等于系统的并发接入能力，而是与系统架构、系统处理能力等各种情况相关。
与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。
##3.5 错误率
定义和解释：错误率简称 FR，指系统在负载情况下，失败交易的概率。错误率＝(失败交易数/交易总数)*100%。
行业参考标准：
不同系统对错误率的要求不同，但一般不超出千分之六，即成功率不低于 99.4%
资源性能指标，常见的可从如下几类进行参考：
定义和解释：CPU 又称为中央处理器，是一块超大规模的集成电路，是一台计算机的运算核心（Core）和控制核心（ Control Unit）。它的功能主要是解释计算机指令以及处理计算机软件中的数据。
行业参考标准：
CPU 指标主要指的 CPU 利用率，包括用户态 (user)、系统态 (sys)、等待态 (wait)、空闲态 (idle)。
定义和解释：内存是计算机中重要的部件之一，它是与 CPU 进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的，因此内存的性能对计算机的影响非常大。
行业参考标准：
现在的操作系统为了最大利用内存，在内存中存放了缓存，因此内存利用率 100% 并不代表内存有瓶颈，衡量系统内存是否有瓶颈主要靠 SWAP（与虚拟内存交换）交换空间利用率，一般情况下，SWAP 交换空间利用率要低于 70%,太多的交换将会引起系统性能低下。
定义和解释：磁盘吞吐量简称为 Disk Throughput，是指在无磁盘故障的情况下单位时间内通过磁盘的数据量。
行业参考标准：
磁盘指标主要有每秒读写多少兆，磁盘繁忙率，磁盘队列数，平均服务时间，平均等待时间，空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的的重要依据，一般情况下，磁盘繁忙率要低于 70%。
定义和解释：网络吞吐量简称为 Network Throughput，是指在无网络故障的情况下单位时间内通过的网络的数据数量。单位为 Byte/s。网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。当网络吞吐量指标接近网络设备或链路最大传输能力时，则需要考虑升级网络设备。
行业参考标准：
网络吞吐量指标主要有每秒有多少兆流量进出，一般情况下不能超过设备或链路最大传输能力的 70%。
常用的中间件例如 Tomcat、Weblogic 等指标主要包括 JVM, ThreadPool, JDBC,具体如下：
行业参考标准：
常用的数据库例如ＭySQL 指标主要包括 SQL、吞吐量、缓存命中率、连接数等，具体如下：
行业参考标准：
一般来说，对于正常工作日（8 小时）运行的系统，至少应该能保证系统稳定运行８小时以上。
对于 7*24 运行的系统，至少应该能够保证系统稳定运行 24 小时以上。如果系统不能稳定的运行，上线后，随着业务量的增长和长时间运行，将会出现性能下降甚至崩溃的风险。
参考标准：
定义和解释：是指应用软件或操作系统以群集方式部署，增加的硬件资源与增加的处理能力之间的关系。
计算公式为：（增加性能/原始性能）/（增加资源/原始资源）*100%。
扩展能力应通过多轮测试获得扩展指标的变化趋势。一般扩展能力非常好的应用系统，扩展指标应是线性或接近线性的，现在很多大规模的分布式系统的扩展能力非常好。
参考标准：
理想的扩展能力是资源增加几倍，性能就提升几倍。扩展能力至少在 70% 以上。
对于服务端性能测试，从系统可靠性指标度量分析时，常见从三类来入手：
对于将双机热备作为可靠性保障手段的系统，可衡量的指标如下：
对于使用集群方式的系统，主要通过以下方式考量其集群可靠性：
本指标为了验证系统的备份/恢复机制是否有效可靠，包括系统的备份和恢复、数据库的备份和恢复、应用的备份和恢复，包括以下测试内容：
其中上述提到的【可扩展指标】和【可靠性指标】，大多数公司在开展性能测试的时候很少会涉及到这些测试点，但这些点从产品整体性能和质量角度来讲，又是不得不关注的一些重点，算是给大家提供一些测试思路。
