简谈性能优化（上）

本文以及接下来的两篇文章会讨论一些性能优化相关的知识，分为上、中、下三个部分。第一部分讨论性能分析的基础内容，第二部分讨论实际的性能分析、调优及测试，第三部分讨论虚拟化环境和云计算环境下的性能。文章内容来自于阅读《图解性能优化》一书的相关笔记和知识整理以及本身的理解。

转在此处本身对于本书的豆瓣书评。

做者给出的是一种总揽大局的思惟观念，而并不是详细的性能解决方式。它只是提供了一些角度去考虑性能问题，怎样排查性能问题，怎样解决的途径和突破点可能在何处。书中的示例也并不是适用于全部的架构，但能够类比类似的解决方案到其余系统。若是事先没有对网络知识有必定了解，就不能理解在网络过程当中存在的性能瓶颈，对操做系统的内在结构不熟悉，也就没法体会中断处理、锁机制等等对性能开销带来的影响。因此工程应用的解决方案每每是科学问题，这些是计算系统架构的底层和基础。

《图解性能优化》重在图解，但同全部的图解类图书通常，图虽浅显但也局限。只是更容易去理解一种思路，并不能带来知识体系的丰富。对于硬件性能的优化，也没有机会去实践。做为软件开发人员，也给了一种全局观察整个架构的机会。方法是次要的，基础扎实能够创造方法，书是引路人，只是让咱们走得更容易些。对于经验丰富的工程师而言，经验已经融入血液，遇到问题能够四两拨千斤，迅速定位。做者能给出浅显的经验和解决方式是很棒的，软技能也存在与书中不少地方，能讲出来已是读者的一种幸运。——@Rainy

性能的基础知识

性能问题的发生每每归结于软件问题和硬件问题两个方面。这里的软件问题是指“应用服务”软件，深刻到软件的核心，是各类算法带来的性能差距。经典算法和数据结构已经很是成熟，由软件形成的性能表现不佳也很可能是对算法应用的不合理。各类算法都有其相应的适用场景，对算法数据结构优缺点的把握则是设计良好软件和架构的基础。而算法也并不是彻底适应与某一个场景，重要的是“折中”思惟。性能问题每每都是速度和成本的权衡，算法也亦然。例如索引能够加快查找速度，但少许查找时又显得多余，预见到将来查找的增长，进行数据索引仍是有必要的过程。下面来简要概述与性能有关的一些算法及优缺点：

性能与算法

算法	优势	缺点	改进变种
数组O(n)	善于循环处理，按序存放、查找数据	未知数组长度，浪费内存空间，数据增多时修改不易	数组的数组，用一个数组来添加位置变量
链表O(n)	管理容易变化的数据，增删数据方便	须要访问动态计算的地址，没法直接同数组下标般找到位置，只能遍历	双向链表
树O(logn)	随数据增长复杂度增长缓慢，查找范围逐渐缩小	数据更新不便，删除数据形成空位，影响性能，致使索引碎片化	n叉树、B树、B+树、B*树
散列算法O(1)	消除数据的不平衡，直接查找	相同数据、相同散列值出现碰撞	以链表结构链接，“重散列”
队列O(1)	大量处理，先入队列，分割事务（缓冲）	队列溢出的状况	数组链接的环形结构的队列，用树结构实现快速查找的队列
栈O(1)	只占用必要空间，无碎片	适用状况少	栈轨迹，以栈形式展示函数调用
快速排序O(nlogn)	加快查找时间，了解重复状况	对频繁查找有价值，对少许查找则费时间	归并排序
缓存（回写）	不用等待写入延时	可能致使缓存丢失时出现数据不一致现象	非易失性(Non-volatile)、电池备份来解决数据丢失
缓存（直写）	数据较快地读取和写入	响应变慢	关机缓存步骤，DBMS日志实时写入

锁与性能

锁机制是为保护数据的完整性及保证数据同步而存在于并行处理中的一种方式，而当锁出现了锁等待，则会造成请求队列。形成请求堆积而致使性能降低，因此须要减小锁等待的发生。

对 DB 而言，提升对表加锁的 SQL 处理速度，能够尽快释放锁。或对行加锁来并行执行，就能够经过分割锁的方式来减小等待时间。

响应与吞吐

考虑性能时，响应与吞吐是两个重要的概念。响应是应答快慢，而吞吐是处理数量。有的系统偏重于响应，而有的偏重于吞吐。经过升级硬件来提升响应速度，通常也会提升吞吐，但升级不是无限的，有它的瓶颈和上限。吞吐不够时，增长响应只是增长了空转的硬件，并不能解决问题。因此当出现性能问题时，要判断是响应问题仍是吞吐问题，对症下药。

性能分析的基础

要进行性能分析首先要进行性能测量，找出问题所在。而性能测量也就是性能分析的原则，首先要从时间和位置两个角度考虑，也就是“分段查找”的思想。从时间角度是测量某个时间段内的性能信息来进行分析，而位置角度则是测量可能发生性能问题的位置进行定点测量，各个击破。而且在测量过程当中，也要考虑性能测量工具的负载对系统的影响。避免对性能信息进行误判。

做者将性能信息分为三类：

1. 概要形式。得到的是某段时间内的平均值，适合快速掌握初步信息。
2. 事件记录形式。得到的是“某时某刻谁作了什么”之类的详细信息，对系统压力较大。不适合常常在生产环境中使用。
3. 快照形式。记录某一瞬间的信息，适合查找引发性能问题的缘由。

三类信息得到以后进行结合分析，来找出问题所在。而获取三类信息的相应工具和命令，会在下面给出。

等待队列理论

在性能方面，“等待队列理论”具备很强的表明性。首先，队列中的等待时间称为“访问等待时间”，有以下关系：

响应时间 = 访问等待时间 + 服务时间

等待队列能够表示为"M/M/1"。分别表示请求到达时间的特征，服务时间的特征，处理的并行程度（1 指线性处理）。由于请求是彻底随机的，因此出现短暂的大量请求，也会产生等待队列。

假设处理时间是 1 秒，每小时处理的条数是 3000 条。

ρ(平均使用率) = [1(处理时间)×3000(处理条数)]/3600(单位时间) = 0.83
等待时间/1秒 = 0.83/（1-0.83）= 4.88
响应时间 = 4.88(等待时间)+1(处理时间)

由上面的式子能够看出，当平均使用率增长的时候，等待时间呈指数级别增长。

在 CPU 使用率的统计工具中，有时能够看到尖峰的出现。频繁的尖峰出现每每是系统出现问题的前兆，但少数尖峰的出现是容许存在的，使用超线程能够改善此现象。然而在批处理中不该该存在这样的状况，处理时间久也不会致使等待队列的变长，因为不能经过等待队列的状况来判断性能问题，这时就应判断单个处理器的时间长度了。

当调查引发性能问题的缘由时，须要肯定一些必要的检测信息。而对于须要得到哪些信息，并无统一的标准。须要按照实际状况去确认。

获取性能信息的 OS 命令

对于获取性能信息的方式，须要了解一些得到信息的 OS 命令。对于 Linux 主要经过内置的命令来得到，Windows 大都是获取相应信息的图形化界面。此外有时还须要其余的工具或软件，例如对网络进行性能分析时，须要使用 Wireshark 来进行抓包分析。下面简要介绍相关命令，具体使用可查阅相关手册（提供的是得到信息的方式和思路，而非详细的使用和操做步骤）。

Linux

对于 Linux 而言，获取性能信息的 OS 命令能够根据性能信息的分类以下：

1. 获取概要信息：

   sar, vmstat, netstat, iostat, profiler

2. 获取快照信息：

   ps, netstat, top, pstack

3. 事件记录形式的信息：

   数据包转储程序, strace

Windows

Windows 的性能信息工具每每隐藏在控制面板的各个角落，比较有用的有任务管理器、性能监视器、资源监视器等。

---

关于性能优化的基础部分谈到这里，第二部分将会谈到实际的性能优化、分析及调优。