支付宝LR集群压测报告

支付宝压力测试报告

时间:2016-03-23                                             测试人员:XXX

目录

支付宝压力测试报告 1

目录 1

一  测试内容 2

二  测试方法 2

三  测试目标 2

四  测试环境 2

五  系统部署 3

5.1 网络访问 3

六  性能测试结果与分析 3

6.1 LR集群压测(1) 3

6.2 LR集群压测(10) 6

6.3 LR集群压测(20) 9

6.4 LR集群压测(30) 12

6.5 LR集群压测(40) 15

6.6 LR集群压测(50) 18

6.7 LR集群压测(60) 21

6.8 LR集群压测(70) 24

七  结果汇总分析 27

一  测试内容

本次测试是针对支付宝快捷支付系统进行的压力测试,在交易接口中,只对交易接口进行压力测试,其中涵盖数据验签与签名功能。

二  测试方法

本次采用LoadRunner的专业测试工具进行集群分布式压测,采用本地动态拼装请求数据并通过http协议post方式发送支付请求。采用闭环压测,交易流程关闭访问ECIF与ICQ服务,但包含解析和拼装ICQ交互报文。

三  测试目标

1) 获取在单机部署情况下最大TPS值

2) 当某些资源耗尽时的最大TPS值

四  测试环境


环境


机器型号


操作系统


硬件cpu


硬件mem


客户端


server2008虚拟机


windows


8核


16G


服务端


Red Hat


linux


64核


126G

Weblogic容器采用线程1500,连接池最小300最大600连接数

Oracle数据库最大连接数2000

五  系统部署

5.1 网络访问

压力测试通讯流程:LR--->F5--->apache server--->F5--->支付宝应用--->数据库

六  性能测试结果与分析

6.1 LR集群压测(1)


Client系统


并发


时间


198.203.208.82


0


10


198.203.208.83


1


10


198.203.208.84


0


10


198.203.208.85


0


10

6.1.1 聚合报告

6.1.2 每秒的响应分布图

6.1.3 响应时间分布图

6.1.4 Client系统资源占用分布图

6.1.5 Server系统资源占用分布图

6.2 LR集群压测(10)


Client系统


并发


时间


198.203.208.82


3


10


198.203.208.83


3


10


198.203.208.84


2


10


198.203.208.85


2


10

6.2.1 聚合报告

6.2.2 每秒的响应分布图

6.2.3 响应时间分布图

6.2.4 Client系统资源占用分布图

6.2.5 Server系统资源占用分布图

6.3 LR集群压测(20)


Client系统


并发


时间


198.203.208.82


5


10


198.203.208.83


5


10


198.203.208.84


5


10


198.203.208.85


5


10

6.3.1 聚合报告

6.3.2 每秒的响应分布图

6.3.3 响应时间分布图

6.3.4 Client系统资源占用分布图

6.3.5 Server系统资源占用分布图

6.4 LR集群压测(30)


Client系统


并发


时间


198.203.208.82


8


10


198.203.208.83


8


10


198.203.208.84


7


10


198.203.208.85


7


10

6.4.1 聚合报告

6.4.2 每秒的响应分布图

6.4.3 响应时间分布图

6.4.4 Client系统资源占用分布图

6.4.5 Server系统资源占用分布图

6.5 LR集群压测(40)


Client系统


并发


时间


198.203.208.82


10


10


198.203.208.83


10


10


198.203.208.84


10


10


198.203.208.85


10


10

6.5.1 聚合报告

6.5.2 每秒的响应分布图

6.5.3 响应时间分布图

6.5.4 Client系统资源占用分布图

6.5.5 Server系统资源占用分布图

6.6 LR集群压测(50)


Client系统


并发


时间


198.203.208.82


13


10


198.203.208.83


13


10


198.203.208.84


12


10


198.203.208.85


12


10

6.5.1 聚合报告

6.5.2 每秒的响应分布图

6.5.3 响应时间分布图

6.5.4 Client系统资源占用分布图

6.5.5 Server系统资源占用分布图

6.7 LR集群压测(60)


Client系统


并发


时间


198.203.208.82


15


10


198.203.208.83


15


10


198.203.208.84


15


10


198.203.208.85


15


10

6.7.1 聚合报告

6.7.2 每秒的响应分布图

6.7.3 响应时间分布图

6.7.4 Client系统资源占用分布图

6.7.5 Server系统资源占用分布图

6.8 LR集群压测(70)


Client系统


并发


时间


198.203.208.82


18


10


198.203.208.83


18


10


198.203.208.84


17


10


198.203.208.85


17


10

6.8.1 聚合报告

6.8.2 每秒的响应分布图

6.8.3 响应时间分布图

6.8.4 Client系统资源占用分布图

6.8.5 Server系统资源占用分布图

七  结果汇总分析


交易


并发


时间


笔数


TPS


峰值TPS


平均TPS


LR_AVE


Server_AVE


LR_CPU%


Client_CPU%


支付


1


10


7267


12.071


30.30


12.11


33


27.8814


8.036


0.6


支付


10


10


66366


110.06


250.00


110.61


40


34.4553


20.998


5.9


支付


20


10


119839


198.738


444.44


199.73


45


36.7229


32.217


9


支付


30


10


147239


244.177


491.80


245.40


61


49.4711


42.554


12.2


支付


40


10


150226


249.131


425.53


250.38


94


79.5005


40.763


13.2


支付


50


10


156413


258.962


406.50


260.69


123


105.454


41.17


12.4


支付


60


10


156676


259.825


338.98


261.13


177


140.863


41.078


12


支付


70


10


158318


262.551


360.82


263.86


194


170.73


40.648


12.3

时间: 2024-10-10 22:07:10

支付宝LR集群压测报告的相关文章

legend分布式服务器集群压测结果

(如果图小,可以Ctrl+鼠标滚轮给缩放) 以下是并发上线1.5万人时的测试结果,如果只是测试万人级别的承载量单网关单逻辑服单数据服的架构将比分布式集群的服务器架构速度更快 本次测试为整个集群只配置了单个对外网关服务器与单个对内逻辑服务器,每个客户端从登陆到上线进场景将会发送与接收并处理了13条消息,其中包括读与写数据库,分10个机器人来批量同时进行上线,前5个机器人每个上线2000个,后5个机器人每个上线1000个,一共是15000个,因此一共处理了15000*13=195000条消息的收发与

Jmeter集群压测环境搭建

一.准备 最好三台服务器,一台做master,两台做agent 二.配置 apache-jmeter-5.2/bin目录下的jmeter.properties文件修改 master:remote_hosts=#agent机器的IP:端口,如remote_hosts=192.168.12.21:1099,192.168.12.22:1099 server.rmi.ssl.disable=true agent: remote_hosts=127.0.0.1 server.rmi.ssl.disabl

SSDB性能压测报告

测试场景 机器: 两台Intel(R) Xeon(R) E5506  2.13GHz  (4核 8线程)*2/内存32GB/SAS 300G 数据: key: 10位顺序数字     value: 50字节      数据量: 2kw 并发: 并发数依次为10.20.40.80.160 压测工具:redis-benchmark ssdb 版本: 1.9.2 ssdb 配置: leveldb: cache_size: 5120 block_size: 32 write_buffer_size: 6

MySQL 5.6 VS 5.7压测报告

  MySQL 5.6 VS 5.7压测报告   版本 姓名 时间 V1.0 刘占彬 2016.3.2   测试条件 1.        软件 OS:  CentOS release 6.7 (Final) 文件格式:xfs MySQL:percona5.6.24  VS  5.7.10 关键参数配置(yum install后初始化默认,未做修改): bufferpool大小16G sync_binlog=0 innodb_flush_log_at_trx_commit= 2 压测工具:sysb

针对httptest4net构建elasticsearch集群压力测用例

httptest4net是可以自定义HTTP压力测试的工具,用户可以根据自己的情况编写测试用例加载到httptest4net中并运行测试.由于最近需要对elasticsearch搜索集群进行一个不同情况的测试,所以针对这个测试写了个简单的测试用例. 代码 [Test("ES base")] public class ES_SearchUrlTester : IUrlTester { public ES_SearchUrlTester() { } public string Url {

关于springmvc的hello world的压测报告

都说hello world 很简单,应该能承受很大的请求压力,那么到底有多大?你知道吗?如果知道,那咱们就不继续了.如果不知道,我们来看一下! 1. 准备工作,快速建立一个基于springmvc的helloworld 1.1. 在pom.xml引入spring必须的包级日志组件 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/PO

安装k8s集群(亲测)

先安装一台虚拟机,然后进行克隆,因为前面的步骤都是一样的,具体代码如下: Last login: Mon Nov 25 00:40:34 2019 from 192.168.180.1 ##安装依赖包 [[email protected] ~]# yum install -y conntrack ntpdate ntp ipvsadm ipset jq iptables curl sysstat libseccomp wget vim net-tools git 已加载插件:fastestmir

大并发的压测使用阿里的TPS(工具推荐篇)

前言: 先说下写这篇博客的由来,因双十一来临,作为电商,日活百万的产品是需要做双十一的压测的.根据当前线上qps为3600来计算,双十一的目标翻十倍,qps达到36000,当前的压测结果:1万的并发qps为2万,所以推测出大概并发在1w5左右(推测的东西会随便具体情况变化而变化),对于这种万级的并发,我觉得有条件可以搭建集群jmeter压测,那么就要考虑资源例如1万5的并发,一台支持500的并发就得30台机器,这个单机支持多少并发可以用压测的某个接口尝试下压测,根据当前机配置扩展,如果机器能到1

实战Centos系统部署Codis集群服务

导读 Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有明显的区别 (不支持的命令列表), 上层应用可以像使用单机的 Redis 一样使用, Codis 底层会处理请求的转发, 不停机的数据迁移等工作, 所有后边的一切事情, 对于前面的客户端来说是透明的, 可以简单的认为后边连接的是一个内存无限大的 Redis 服务. 一.Codis简介 Codis 是 Wandoujia Infrastructu