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

桃扇骨 2022-09-21 11:42 248阅读 0赞

这篇博文主要是涉及到服务端性能，对于前端性能比较少涉及，但是最后一部分简单介绍了前端（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）

**\[html\]**  [view plain][]   [copy][view plain]

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

使用这些测试工具并不难，难的是从测出来的数据看出是否正常，不同的语言，不同的架构的系统的性能可能存在不小的差别。我这里只是简单说个大概的性能指标。  
    1）TPS（QPS）：如果每次都需要访问数据库的业务，一般100-500之间，低于100有优化的空间；不需要访问数据库，都是内存访问的，500-1500都有可能；访问磁盘和其他模块有交互的服务，就介于这两者之间了。  
    2）平均响应时间：还是分情况，如果访问数据库等，100-500ms之间；不访问数据库，根据业务的复杂程度，在30-300ms之间了。

如果是Socket，那么需要自己写Socket Client程序，其实也简单，就是多线程发包工具，同时统计好响应时间。  
  发包工具的参数设置，其实有比较多需要注意的地方，如下：

**\[html\]**  [view plain][]   [copy][view plain]

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

**四、服务器端性能指标**  
  我之前写过一些博文，较为详细的介绍了服务器端的性能指标。  
  [LoadRunner压力测试时监控服务器Linux的资源情况][LoadRunner_Linux]  
  [压力测试衡量CPU的三个指标：CPU Utilization、Load Average和Context Switch Rate][CPU_CPU Utilization_Load Average_Context Switch Rate]  
  [高性能服务器架构(High-Performance Server Architecture)][High-Performance Server Architecture]  
  [设置正确的线程数量][Link 1]  
  [网站性能测试PV到TPS的转换以及TPS的波动][PV_TPS_TPS]

**\[html\]**  [view plain][]   [copy][view plain]

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

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

**\[html\]**  [view plain][]   [copy][view plain]

1.  IOPS = 1000 / RS  
2.  RS为磁盘服务时间，他由三个部分构成：平均寻道时间、旋转延迟、内部传输时间。平均寻道时间指磁头达到目标磁道所需要时间，这个和磁盘的电机等相关；旋转延迟指到达磁道之后，旋转到目的扇区所需要的时间，这个时间和磁盘的转速相关，转速越高，这个时间越低，比如15000转/分钟的磁盘，那么旋转延迟时间为2ms；内部传输时间，指向磁盘读写数据的时间，这个时间比较少，可以忽略不计。  
3.    
4.  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的性能跟踪工具  
  具体的用法，请大家自行搜索。

[view plain]: http://blog.csdn.net/marising/article/details/39338721#
[LoadRunner_Linux]: http://blog.csdn.net/marising/article/details/5160210
[CPU_CPU Utilization_Load Average_Context Switch Rate]: http://blog.csdn.net/marising/article/details/5182771
[High-Performance Server Architecture]: http://blog.csdn.net/marising/article/details/5186643
[Link 1]: http://blog.csdn.net/marising/article/details/5272193
[PV_TPS_TPS]: http://blog.csdn.net/marising/article/details/5713314