分布式微服务系统架构第91集：系统性能指标总结

加群联系作者vx：xiaoda0423

仓库地址：https://webvueblog.github.io/JavaPlusDoc/

系统性能指标总结

1. 系统性能指标包括哪些？

业务指标、资源指标、中间件指标、数据库指标、前端指标、稳定性指标、批量处理指标、可扩展性指标、可靠性指标。

1）业务指标：主要包括并发用户数、响应时间、处理能力。

响应时间 Response Time: RT

1. 对于在线实时交易：

2. 互联网企业：500毫秒以下，例如淘宝业务10毫秒左右。

3. 金融企业：1秒以下为佳，部分复杂业务3秒以下。

4. 保险企业：3秒以下为佳。

5. 制造业：5秒以下为佳。

6. 对于批量交易：

不同数据量结果是不一样的，大数据量的情况下，2小时内完成。

系统处理能力

1. HPS（Hits Per Second） ：每秒点击次数，单位是次/秒。

2. TPS（Transaction per Second）：系统每秒处理交易数，单位是笔/秒。

3. QPS（Query per Second）：系统每秒处理查询次数，单位是次/秒。

4. 对于互联网业务中，如果某些业务有且仅有一个请求连接，那么TPS=QPS=HPS。

5. 一般情况下，用TPS来衡量整个业务流程，用QPS来衡量接口查询次数，用HPS来表示对服务器点击请求。

无论TPS、QPS、HPS,此指标是衡量系统处理能力非常重要的指标，越大越好。

并发用户数

Virtual User: VU

一般情况下，性能测试是将系统处理能力容量测出来，而不是测试并发用户数，除了服务器长连接可能影响并发用户数外，系统处理能力不受并发用户数影响，可以用最小的用户数将系统处理能力容量测试出来，也可以用更多的用户将系统处理能力容量测试出来。

错误率

Failure Ratio: FR

不同系统对错误率的要求不同，但一般不超出千分之六，即成功率不低于99.4%。

不同系统对错误率的要求不同，但一般不超出千分之六，即成功率不低于99.4%。

2）资源指标：CPU资源利用率、内存利用率、磁盘I/O、网络I/O、内核参数(信号量、打开文件数)等。

CPU Central Processing Unit：CPU

1. CPU指标主要指的CPU利用率，包括用户态(user)、系统态(sys)、等待态(wait)、空闲态(idle)。

2. CPU利用率要低于业界警戒值范围之内，即小于或者等于75%;

3. CPU sys%小于或者等于30%,

4. CPU wait%小于或者等于5%。

5. CPU Load要小于CPU 核数。

内存

Memory就是内存的简称

现代的操作系统为了最大利用内存，在内存中存放了缓存，因此内存利用率100%并不代表内存有瓶颈，衡量系统内有有瓶颈主要靠SWAP（与虚拟内存交换）交换空间利用率，一般情况下，SWAP交换空间利用率要低于70%,太多的交换将会引起系统性能低下。

磁盘吞吐量

磁盘指标主要有每秒读写多少兆，磁盘繁忙率，磁盘队列数，平均服务时间，平均等待时间，空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的的重要依据，一般情况下，磁盘繁忙率要低于70%。

网络吞吐量

网络吞吐量指标主要有每秒有多少兆流量进出，一般情况下不能超过设备或链路最大传输能力的70%。

内核参数主要包括信号量、进程、文件句柄，一般不要超过设置的参数值即可，具体如下:

3）中间件指标：常用的中间件例如Tomcat、Weblogic等指标主要包括JVM, ThreadPool, JDBC。

标准

1. 当前正在运行的线程数不能超过设定的最大值。一般情况下系统性能较好的情况下，线程数最小值设置50和最大值设置200比较合适。

2. 当前运行的JDBC连接数不能超过设定的最大值。一般情况下系统性能较好的情况下，JDBC最小值设置50和最大值设置200比较合适。

3. GC频率不能频繁，特别是FULL GC更不能频繁，一般情况下系统性能较好的情况下，JVM最小堆大小和最大。

4）数据库指标：SQL、吞吐量、命中率、锁。

标准

1. SQL耗时越小越好，一般情况下微秒级别。

2. 命中率越高越好，一般情况下不能低于95%。

3. 锁等待次数越低越好，等待时间越短越好。

5）前端指标：页面加载时间、页面数量、网络时间（DNS，连接时间、传输时间等）。

标准

1. 页面要尽可能小及压缩。

2. 页面展示和花费时间越短越好。

6）稳定性指标

1. 最短稳定时间：系统按照最大容量的80%或标准压力（系统的预期日常压力）情况下运行，能够稳定运行的最短时间。

2. 一般来说，对于正常工作日（8小时）运行的系统，至少应该能保证系统稳定运行８小时以上。对于7*24运行的系统，至少应该能够保证系统稳定运行24小时以上。

3. 标准

4. TPS曲线稳定，没有大幅度的波动。

5. 各项资源指标没有泄露或异常情况。

7）批量处理指标：指批量处理程序单位时间内处理的数据数量。一般用每秒处理的数据量来衡量。

1. 处理效率是估算批量处理时间窗口最重要的计算指标。

2. 关于批量处理时间窗口，不同系统的批量处理时间窗口在起止时间上可以部分重叠。另外，同一系统内部，也可能存在多个批量处理过程同时进行，其时间窗口相互叠加。

3. 标准

4. 在数据量很大的情况下，批处理时间窗口时间越短越好。

5. 不能影响实时交易系统性能。

8）可扩展性指标：指应用软件或操作系统以群集方式部署，增加的硬件资源与增加的处理能力之间的关系。

1. 计算公式为：（增加性能/原始性能）/（增加资源/原始资源）*100%。

2. 扩展能力应通过多轮测试获得扩展指标的变化趋势。

标准

1. 理想的扩展能力是资源增加几倍，性能就提升几倍。

2. 扩展能力至少在70%以上。

9）可靠性指标：双机热备、集群、备份和恢复。

1. 具体性能的分析流程？

首先看关键指标是否满足需求，如果不满足，需要确定是哪个地方有问题，一般情况下，服务器端问题可能性比较大，也有可能是客户端问题（这种可能性非常小）。

如果是服务器端的问题，需要定位的问题有硬件相关指标，例如CPU，Memory，Disk I/O，Network I/O，如果是某个硬件指标有问题，需要深入的进行分析。如果中间件相关指标没问题，需要查看数据库相关指标，例如：慢查SQL，命中率，锁，参数设置。

如果以上指标都正常，应用程序的算法、缓冲、缓存、同步或异步可能有问题，需要具体深入的分析。

1. 如果让你去优化前端页面，你的优化流程是？

遇到问题，第一步是确定问题，先要确定是前端的问题还是后端的问题。如果是前端的问题，那就要确定在哪些地方出了问题，按照前端的各种检测方法来检查。如果是后端的问题，就从系统、中间件、数据库、网络等方面入手。

如何确定问题呢？

比如用Firefox的firebug调试，看一次请求在各部分分别花了多少时间，哪些请求耗时最长。如果请求的是静态资源，时间很长，就需要考虑部署CDN啥的；如果请求的不是静态资源而是服务器数据，时间长速度慢，那就分两种情况进行考虑：第一是后端的问题，第二是前端渲染问题。如果返回数据很快，但界面数据没出来，就要考虑是前端js程序问题还是图片等资源太大的问题等等。

哈希表（Hash Table）：哈希表的原理可以类比银行办业务取号，给每个人一个号（计算出的Hash值），叫某个号直接对应了某个人，索引效率是最高的O(1)，消耗的存储空间也相对更大。K-V存储组件以及各种编程语言提供的Map/Dict等数据结构，多数底层实现是用的哈希表。

二叉搜索树（Binary Search Tree）：有序存储的二叉树结构，在编程语言中广泛使用的红黑树属于二叉搜索树，确切的说是"不完全平衡的"二叉搜索树。从C++、Java的TreeSet、TreeMap，到Linux的CPU调度，都能看到红黑树的影子。Java的HashMap在发现某个Hash槽的链表长度大于8时也会将链表升级为红黑树，而相比于红黑树"更加平衡"的AVL树反而实际用的更少。

平衡多路搜索树（B-Tree）：这里的B指的是Balance而不是Binary，二叉树在大量数据场景会导致查找深度很深，解决办法就是变成多叉树，MongoDB的索引用的就是B-Tree。

叶节点相连的平衡多路搜索树（B+ Tree）：B+ Tree是B-Tree的变体，只有叶子节点存数据，叶子与相邻叶子相连，MySQL的索引用的就是B+树，Linux的一些文件系统也使用的B+树索引inode。其实B+树还有一种在枝桠上再加链表的变体：B*树，暂时没想到实际应用。

日志结构合并树（LSM Tree）：Log Structured Merge Tree，简单理解就是像日志一样顺序写下去，多层多块的结构，上层写满压缩合并到下层。LSM Tree其实本身是为了优化写性能牺牲读性能的数据结构，并不能算是索引，但在大数据存储和一些NoSQL数据库中用的很广泛，因此这里也列进去了。

字典树（Trie Tree）：又叫前缀树，从树根串到树叶就是数据本身，因此树根到枝桠就是前缀，枝桠下面的所有数据都是匹配该前缀的。这种结构能非常方便的做前缀查找或词频统计，典型的应用有：自动补全、URL路由。其变体基数树（Radix Tree）在Nginx的Geo模块处理子网掩码前缀用了；Redis的Stream、Cluster等功能的实现也用到了基数树（Redis中叫Rax）。

跳表（Skip List）：是一种多层结构的有序链表，插入一个值时有一定概率"晋升"到上层形成间接的索引。跳表更适合大量并发写的场景，不存在红黑树的再平衡问题，Redis强大的ZSet底层数据结构就是哈希加跳表。

倒排索引（Inverted index）：这样翻译不太直观，可以叫"关键词索引"，比如书籍末页列出的术语表就是倒排索引，标识出了每个术语出现在哪些页，这样我们要查某个术语在哪用的，从术语表一查，翻到所在的页数即可。倒排索引在全文索引存储中经常用到，比如ElasticSearch非常核心的机制就是倒排索引；Prometheus的时序数据库按标签查询也是在用倒排索引。

定义好主键并尽量使用主键，多数数据库中，主键是效率最高的聚簇索引；

在Where或Group By、Order By、Join On条件中用到的字段也要按需建索引或联合索引，MySQL中搭配explain命令可以查询DML是否利用了索引；

类似枚举值这样重复度太高的字段不适合建索引（如果有位图索引可以建），频繁更新的列不太适合建索引；

单列索引可以根据实际查询的字段升级为联合索引，通过部分冗余达到索引覆盖，以避免回表的开销；

尽量减少索引冗余，比如建A、B、C三个字段的联合索引，Where条件查询A、A and B、A and B and C

都可以利用该联合索引，就无需再给A单独建索引了；根据数据库特有的索引特性选择适合的方案，比如像MongoDB，还可以建自动删除数据的TTL索引、不索引空值的稀疏索引、地理位置信息的Geo索引等等。

首先解析DNS时，浏览器一层DNS缓存、操作系统一层DNS缓存、DNS服务器链上层层缓存；

发送一个GET请求这篇文章，服务端很可能早已将其缓存在KV存储组件中了；

即使没有击中缓存，数据库服务器内存中也缓存了最近查询的数据；

即使没有击中数据库服务器的缓存，数据库从索引文件中读取，操作系统已经把热点文件的内容放置在Page Cache中了；

即使没有击中操作系统的文件缓存，直接读取文件，大部分固态硬盘或者磁盘本身也自带缓存；

数据取到之后服务器用模板引擎渲染出HTML，模板引擎早已解析好缓存在服务端内存中了；

历经数十毫秒之后，终于服务器返回了一个渲染后的HTML，浏览器端解析DOM树，发送请求来加载静态资源；

需要加载的静态资源可能因Cache-Control在浏览器本地磁盘和内存中已经缓存了；

即使本地缓存到期，也可能因Etag没变服务器告诉浏览器304 Not Modified继续缓存；

即使Etag变了，静态资源服务器也因其他用户访问过早已将文件缓存在内存中了；

加载的JS文件会丢到JS引擎执行，其中可能涉及的种种缓存就不再展开了；

整个过程中链条上涉及的所有的计算机和网络设备，执行的热点代码和数据很可能会载入CPU的多级高速缓存。