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

    这篇博文主要是涉及到服务端性能，对于前端性能比较少涉及，但是最后一部分简单介绍了前端（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的性能跟踪工具
  具体的用法，请大家自行搜索。