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