性能测试、指标和优化 -- 性能相关总结

这篇博文主要是涉及到服务端性能，对于前端性能比较少涉及，但是最后一部分简单介绍了前端（Web页面）的测试和调优。这篇文章最早写于2012年，今天翻出来，又重新梳理了一下。哦，对了，如果对本博客中所有文章有疑问，请发邮件到lihaibo2006$gmail.com，我一般晚上就能看到。

一、性能测试的类型

实际上性能是一个很很宽泛的词，系统出了问题大多归结为性能有问题，比如访问速度慢，占用资源过多，时不时宕机等等，但是这属于不同性能问题的范畴，而且测试方法也不尽相同。做性能测试的QA是很稀少的，所以性能测试一般都由工程师来承担。

1、性能测试（可用性测试）

主要是测试正常业务量下，成功率、每秒检索量、平均处理时间、服务器资源利用率。主要考察，该系统是否符合业务需求，能否达到上线要求。

2、压力测试

主要是测试峰值情况下，测试不同并发数下，单机/单套系统的极限并发。和上一个测试不同，这里主要考察万一访问量特别大的情况下，系统是否能够抗住压力，如果超出这个极限，就需要增加硬件设施了。

3、容量测试

主要是测试数据量非常大的情况下，内存、磁盘、访问性能。一般系统刚上线，数据量较小，性能一般没有什么问题，把数据放大到百万、千万量级，再测测系统，可能之前未能暴露的问题就出来了。

4、疲劳测试

连续24小时以上测试，看有没有内存碎片和内存泄露，内存泄露比较好解决，内存碎片这个问题比较棘手。听说Microsoft SqlServer刚发版的时候，一周宕一次，没有办法，只能定期去重启Server。

5、配置测试

不同参数下的性能，后台程序会有很多开关，需要测试主要的开关情况下对性能的影响，或者不同的参数数量对于性能的影响。比较简单的例子就是，索引长度设置为128和1024对于系统的性能究竟有多大的影响。

二、测试前的准备

1、两台干净的同局域网的机器，跨机房的两台机器，你就需要考虑到，机房之间的延迟了。

2、优化的编译选项的程序，最好是优化过的，上线要求的编译设置。

3、服务端、测试程序分开部署

4、检查线程数以及其他参数

5、检查功能是否正确，功能不正常，别做性能测试。

6、关闭Debug日志，debug日志打开，性能瓶颈全在log上了。

7、测试客户端放在另一台机器上

8、准备测试数据，尽量构造和生产环境相同的数据。

9、因等待时间较长，请准备一杯茶 or 咖啡 or 书

三、性能测试工具和指标

性能测试的工具有很多，如果是HTTP协议，那么ApacheBench、Siege、WebBench、LoadRunner（商用）我简单介绍一下ApacheBench（AB）

参数
-n 同时并发数，10-20-50-100
-c 总请求数量，一般够压10分钟左右，10万-100 即可
报告
错误：Complete requests/Failedrequests/Write errors
TPS：Requests per second:  xxx [#/sec] (mean)
平均时间：Time per request:  xx [ms] (mean)
网络：Transfer rate:  xx [Kbytes/sec] received
时间分布：
Percentage of the requestsserved within a certain time (ms)
95%   4398
98%   5608
99%   7368
100%   7785 (longest request)

使用这些测试工具并不难，难的是从测出来的数据看出是否正常，不同的语言，不同的架构的系统的性能可能存在不小的差别。我这里只是简单说个大概的性能指标。

1）TPS（QPS）：如果每次都需要访问数据库的业务，一般100-500之间，低于100有优化的空间；不需要访问数据库，都是内存访问的，500-1500都有可能；访问磁盘和其他模块有交互的服务，就介于这两者之间了。

2）平均响应时间：还是分情况，如果访问数据库等，100-500ms之间；不访问数据库，根据业务的复杂程度，在30-300ms之间了。

如果是Socket，那么需要自己写Socket Client程序，其实也简单，就是多线程发包工具，同时统计好响应时间。

发包工具的参数设置，其实有比较多需要注意的地方，如下：

并发数
并发数和QPS，并发数和QPS没有必然联系，并发数达到一定数量，QPS趋于稳定
并发数和平均响应时间，并发数达到一定数量，平均响应时间增加
寻找合理并发数和最大并发数，合理的并发数就是QPS稳定、响应时间符合业务需要；最大并发数就是QPS曲线平稳，不会来回波动
注意事项
并发数比线程数多一点，10 - 50个
不用太长时间，5 - 20分钟
不用太多记录，几万 - 十几万
模拟真实的请求
注意客户端的资源消耗

四、服务器端性能指标

我之前写过一些博文，较为详细的介绍了服务器端的性能指标。

LoadRunner压力测试时监控服务器Linux的资源情况

压力测试衡量CPU的三个指标：CPU Utilization、Load Average和Context Switch Rate

高性能服务器架构(High-Performance Server Architecture)

设置正确的线程数量

网站性能测试PV到TPS的转换以及TPS的波动

CPU Utilization
利用率总的在75%以上
分为User、System(10%以下)
IDL：保证一定空闲率
Load Average / Process Queue
正在处理和等待的进程数 < CPU * 核 * 0.7
Context Switch Rate
CSR = IR + TPS * N ?
CSR和TPS相关、N太高要注意几千算正常
内存
平稳，无波动
使用率 < 80%
si/so/bi/bo
网络
估算：QPS*ReqPackage/ResPackage

我以前关注磁盘比较少，不过磁盘也有个指标，IOPS（每秒IO）。我之前看到一个图，详细解释了IOPS的估算：

IOPS = 1000 / RS
RS为磁盘服务时间，他由三个部分构成：平均寻道时间、旋转延迟、内部传输时间。平均寻道时间指磁头达到目标磁道所需要时间，这个和磁盘的电机等相关；旋转延迟指到达磁道之后，旋转到目的扇区所需要的时间，这个时间和磁盘的转速相关，转速越高，这个时间越低，比如15000转/分钟的磁盘，那么旋转延迟时间为2ms；内部传输时间，指向磁盘读写数据的时间，这个时间比较少，可以忽略不计。

IO响应时间 = RS / (1-U)，U为IO利用率就是一次IO操作。关于磁盘IO这块的指标分析，下次我再专门写一篇来详细介绍。

对于磁盘的测试，Linux下可以使用dd、fio、iostat去查看，具体的用法，大家自行搜索。

五、性能优化原则

1：在产品不同生命周期性能侧重不同。初期，处于项目尝试阶段，业务量还没有那么大，不要过多关注性能问题，快速上线是主要目标。中期，有一定的用户量，主要是重构系统，为以后优化和扩展功能奠定基础，同时初步优化瓶颈项目。后期维护阶段，性能优化以节省硬件投入，同时需要保证系统稳定。

2：没有证据(当前和预期)不优化，一般来说，过渡设计是应当尽力避免的，过渡的性能优化也同样如此，如果系统运转很好，没有性能问题，就不要去尝试优化，即便是做了优化，也不见得有明显的效果。

3：事实和推测分开、事实验证推测，性能优化应当以数据说话，有测试数据，有对比才能够验证优化的点是否有效。猜测去修改代码，可能效果并不好，而且会破坏原有程序的代码结构。

4：优先验证简单假设，加入有多种可能性，那么先修改和验证简单的假设比较靠谱。

5：从外到内层层剥离，缩小范围到模块

6：模块内部分割单元测试，确定优化目标

内存优化

谨防内存泄露(Valgrind)

避免内存频繁申请和释放(内存池)

内存池：减少内存浪费、CPU消耗、增加程序伸缩性

尽量减少内存拷贝

0拷贝无必要，合理的程序结构更重要

作用域和生命周期相同的数据放一起

进程数据：字典、配置文件

线程数据：线程中各函数公用的数据结构

请求数据：每个请求内的处理数据

函数数据：局部临时数据

性能调优工具

valgrind，检查内存泄露的工具

gprof，gnu profile工具

google performance tools，google的性能跟踪工具

具体的用法，请大家自行搜索。