支付宝的性能测试(2)

发表于:2014-09-25来源:uml.org.cn作者:付丽华 孙玉星点击数: 标签:性能测试
JVM Perm 区内无内存泄露,无内存溢出。GC时间间隔10min,暂停应用时间200ms. 发布时间30S CPU70%, load core*1.5。 3.扫描过程中发布性能场景 性能测试方案: 使

  JVM Perm 区内无内存泄露,无内存溢出。GC时间间隔>10min,暂停应用时间<200ms.

  发布时间<30S

  CPU<70%, load < core*1.5。

  3.扫描过程中发布性能场景

  性能测试方案:

  使用jmeter脚本进行分布式压测,同时提交发布请求进行发布。

  同时使用扫描性能场景和发布性能场景收集数据功能。

  通过标准:

  RT < 扫描性能场景结果RT * 110%.

  TPS > 扫描性能场景结果TPS * 90%.

  发布时间 < 40s。

  d. 发现的问题

  1. 扫描性能场景

  AVG RT = 473ms, CMS GC = 90ms, 应用暂停时间 = 1s, 因此测试未通过。

  问题定位:

  dump内存,使用ibm memory analyzer 分析。

  确认cms gc的原因为drools引擎的finalize方法。Finzlize方法不能正确的释放对象的引用关系,导致引用关系一直存在,无法释放。

  调优方案:

  根据drools的升级文档,升级drools引擎后解决此问题

  2. 发布性能场景

  CMS GC 回收失败,内存无法被释放,应用宕机。

  问题定位:

  GC回收比例为默认值68%,OLD区内存1024M,那么回收的临界值为1024*0.68=696.32M。系统的JVM内存占用为500M,扫描策略相关的内存为120M,在切换的过程中,依赖额外的120M,因此只有在可用内存大于740M时才能正常回收。

  解决方案:

  调整JVM参数,扩大GC回收比例。

  后续技术方案改造,使用增量发布解决此问题。

  3. 扫描过程中发布性能场景

  问题定位:

  扫描平台发布流程,当首次请求进来时执行脚本动态编译过程,由于脚本较多,因此所有脚本的动态编译时间较长,在此过程中,进来的所有请求都会被hand住,造成大量超时

  解决方案:

  把脚本的动态编译提前到首次请求调用进来之前,编译通过后再切换扫描引擎,保证首次请求进来前一切准备就绪。

  三:性能测试的执行和结果收集

  3.1性能测试的执行

  性能测试的执行需要具备以下几个条件:施压工具,测试环境以及对测试结果的收集工具。

  3.1.1 施压工具

  我们先来说说施压工具,支付宝使用的主流施压工具是开源工具Apache JMeter,支持很多类型的性能测试:

  Web - HTTP, HTTPS

  SOAP

  Database via JDBC

  LDAP

  JMS

  任何用java语言编写的接口,都可二次开发并调用。

  支付宝大部分接口是webservice接口,基于soap协议,且都是java开发,所以使用jmeter非常方便,即使jemter工具本身没有自带支持的协议,也可以通过开发插件的方式支持。

  3.1.2测试环境

  测试环境包括被压机和施压机环境,需要进行硬件配置和软件版本确认,保证系统干净,无其他进程干扰,最好能提前监控半小时到1小时,确认系统各项指标都无异常。

  另外除了被压机和施压机,有可能应用系统还依赖其他的系统,所以我们需要明确服务器的数量和架构,1是方便我们分析压力的流程,帮助后面定位和分析瓶颈,2是由于我们线下搭建的环境越接近线上,测试结果越准确。但是通常由于测试资源紧张或者需要依赖外围,例如银行的环境,就会比较麻烦,通常我们会选择适当的进行环境mock。当然,Mock的时候尽量和真实环境保持一致,举个简单的例子,如果支付宝端系统和银行进行通信,线上银行的平均处理时间为100ms,那么如果我们在线下性能测试时需要mock银行的返回,需要加入100ms延迟,这样才能比较接近真实的环境。

  另外除了测试环境,还有依赖的测试数据也需要重点关注,数据需要关注总量和类型,例如支付宝做交易时,db中流水万级和亿级的性能肯定是不一样的;还有db是否分库分表,需要保证数据分布的均衡性。一般考虑到线下准备数据的时长,一般性能测试要求和线上的数据保持一个数量级。

  3.1.3 测试结果收集工具

  测试结果收集主要包括以下几个指标:

  响应时间、tps、错误率、cpu、load、IO、系统内存、jvm(java虚拟内存)。

  其中响应时间、tps和业务错误率通过jemter可以收集。

  Cpu、load、io和系统内存可以通过nmon或linux自带命令的方式来监控。

原文转自:http://www.uml.org.cn/Test/201406112.asp?artid=1785