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

标签: 性能 测试 指标 | 发表时间:2014-09-17 14:03 | 作者:marising
出处:http://blog.csdn.net

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

作者:marising 发表于2014-9-17 14:03:37 原文链接
阅读:61 评论:0 查看评论

相关 [性能 测试 指标] 推荐:

web性能测试指标

- - 研发管理 - ITeye博客
Web性能测试的部分概况一般来说,一个Web请求的处理包括以下步骤:. (2)web server接受到请求,进行处理;. (3)web server向DB获取数据;. (4)webserver生成用户的object(页面),返回给用户. 给客户发送请求开始到最后一个字节的时间称为响应时间(第三步不包括在每次请求处理中).

web性能测试基本性能指标

- - 互联网 - ITeye博客
Web性能测试的部分概况一般来说,一个Web请求的处理包括以下步骤:.     (1)客户发送请求.     (2)web server 接受到请求,进行处理;.     (3)web server 向DB获取数据;.     (4)web server生成用户的object(页面),返回给用户. 给客户发送请求开始到最后一个字节的时间称为响应时间(第三步不包括在每次请求处理中).

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

- - CSDN博客架构设计推荐文章
    这篇博文主要是涉及到服务端性能,对于前端性能比较少涉及,但是最后一部分简单介绍了前端(Web页面)的测试和调优. 这篇文章最早写于2012年,今天翻出来,又重新梳理了一下. 哦,对了,如果对本博客中所有文章有疑问,请发邮件到lihaibo2006$gmail.com,我一般晚上就能看到.     实际上性能是一个很很宽泛的词,系统出了问题大多归结为性能有问题,比如访问速度慢,占用资源过多,时不时宕机等等,但是这属于不同性能问题的范畴,而且测试方法也不尽相同.

mongodb性能测试

- - 数据库 - ITeye博客
1) Mongodb的非安全插入方式,在一开始插入性能是非常高的,但是在达到了两千万条数据之后性能骤减,这个时候恰巧是服务器24G内存基本占满的时候(随着测试的进行mongodb不断占据内存,一直到操作系统的内存全部占满),也就是说Mongodb的内存映射方式,使得数据全部在内存中的时候速度飞快,当部分数据需要换出到磁盘上之后,性能下降很厉害.

WebService性能测试

- - ImportNew
(本文也会在最下面通俗的介绍). 这里给一个站内大哥的讲解: http://www.cnblogs.com/Leo_wl/archive/2010/05/20/1740205.html. 简单点就是测试WebService的一个工具. 官网地址: http://www.soapui.org/. ps:官网是英语的,如果你英语不好的话可以使用谷歌浏览器或360极速浏览器,它可以自动把英文转换成中文.

linux 系统性能指标

- - 非技术 - ITeye博客
近段时间,再忙着找实习,经常被问到的,关于linux系统性能的指标,比如对于一台linux机器来说,怎么监控它的CPU,内存,负载等情况;怎样算高负载,具体的依据是什么. 等等这类问题,下面就好好总结一下这方面知识吧~. 由于能力有限,可能总结的不是很全面,不是很正确,有错漏的,欢迎大家帮忙指出,谢谢.

性能测试工具 CBenchmark

- lele - 开源中国社区最新软件
CBenchmark—-CharlesCui’s Benchmark 这是我实现的一款性能测试工具,之前在工作中常用LoadRunner之类的工具来完成性能测试,但受限于LR极其昂贵的Lisence以及难以定制的SDK,于是我用C/C++实现了这个工具,并借助Linux系统对线程和进程的良好调度,可以实现极高的并发压力.

浏览器性能测试

- - Taobao QA Team
浏览器作为一个浏览网页的平台,自身的性能直接影响网页的解析速度、渲染,而浏览器的性能一般又是由浏览器的内核来决定. 虽然浏览器的评测方法有很多,但是权威的浏览器性能测试方法主要有以下几种:. Acid3测试是检测浏览器与Web标准兼容性的主要方法,也是目前行业中最权威的测试. Acid3是由网页标准计划小组(Web Standards Project, WaSP)设计,测试焦点集中在ECMAScript、DOM Level 3、Media Queries和data: URL,浏览器开启 http://acid3.acidtests.org/测试页面后,页面会不断加载功能、直接给予分数.

Android应用性能测试

- - CSDN博客推荐文章
java虚拟机有内存使用上限的限制. adb shell进入手机,这此参数被纪录在/system/build.prop中,如果想直接查看可以使用adb shell getprop. 单个应用程序最大内存限制,超过这个值会产生OOM. 单个java虚拟机最大的内存限制,超过这个值会产生OOM. android程序内存一般限制在16M,当然也有24M的,而android程序内存被分为2部分:.

【闲说】性能测试

- - 并发编程网 - ifeve.com
版权声明:本文为本作者原创文章,转载请注明出处. 感谢 码梦为生| 刘锟洋 的投稿. 性能测试是一件看起来不简单,操作起来确更困难的事情,我认为,每认真做一次性能测试,一定会有不同收获,而每次性能测试暴露的问题,现象都不是仅仅涉及Java,tomcat这么简单,简单说就是光会写代码是无法做好性能测试的.