基于业务封装API进行Redis服务性能测试记录

标签：style   blog   http   ar   使用   sp   文件   on   数据   

背景

         开发方面给予redis开源客户端做了二次封装，且做了reids集群部署；ld要求对redis服务性能做一次摸底测试；

测试需求

1. 单实例的读写压力极限
2. 单机的读写压力极限(可能瓶颈在网卡)
3. proxy单实例的压力极限
4. proxy单机的压力极限
5. 主备的切换的可靠性测试 ------------ 本次未做
6. 平滑迁移的有效性  ------------ 本次未做
7. 迁移对访问性能的影响(可选) ------------ 本次未做

从上述开发提出的需求看出，本次是以性能验证为主要目的的一次测试；运行场景为通过封装的API，及不同实例配置来验证处理能力；

测试准备工作

1、业务分析；

• 1个proxy实例可能对应多个redis实例;
• 实际业务目前只有一个主实例；
• 理想情况：每个redis实例分别有主、备2个实例；
• 业务调用都是通过redis_access.h文件中的方法来使用的；
• redis_access.h中封装有8个公共方法作为api；

----------- 其实都是拼装命令、参数后使用RAcess::Query来进行执行；

----------- 另外封装有序列化，以及从CA中查询IP端口等方法；读：Get，写：SetNX/Set，删除：Del；其中用的最多的是Get和SetNX；

----------测试时采用Set；

区别：

SetNX对key有判断，如果key存在则不写入；

Set：无论是否存在都进行写入动作；

•  数据长度，无法确定具体业务长度可能是多少；此处采取两种业务长度

　　　　A、1024字节；---- 测试单实例、单机极限；

　　　　B、114字节；----- 测试实际业务及各配置实例数的表现；

• 业务模型：

a、 Redis实例进行RDB备份；AOF备份；

RDB：时间间隔内生成数据集的时间点快照；

AOF：实时记录所有的写操作命令和数据； ----- 这个文件会很大，目测是有单读的脚本进行备份等处理；

b、主实例写入后同步给备份实例；主实例挂掉后，JCA切换配置配置中心服务为备份实例的IP端口；

2、用例设计（此处与业务数据一起贴出

a)         采用并发测试，峰值模型；

PS: 单实例600时失败数量已经0.03%，继续加大只会增加失败率;

环境准备工作

•  Redis集群配置：由redis集群平台配置（BID，实例，设备等），同时需要部署CA，注册机器设备；

•  服务器配置

• 服务部署:IP略；RPM：redis服务，redis_stencel，tweprox，共2redis服务（1主1备），6加压机，2proxy机器；

脚本开发工作

• 压力工具：test_client框架（C++编写），修改框架代码分段传参；编写业务脚本，采用中奖结构体，2个字段；长度控制：重复填充对象；
• 服务器性能数据收集：sar/vmstat/mpstat/top等工具手工收集；

测试执行和数据分析

1. 执行：手工执行；
2. 服务器数据简介：

• Proxy：
• 114B时10实例，800并发，总cpu低于20%，，部分内核吃满；开启irqbalance后依然如此；磁盘写入很低，内存/网卡等占用正常；
• 1024时，单实例600写并发；网卡200MB+；假设继续加实例和并发，则网卡很容易就被吃满；
•  Redis：114B时，800并发，redis总CPU30%左右；部分内核吃满，修改部分参数，开启irqbalance后，分布平均；磁盘写入正常，并不大；网卡在15~20MB左右；

开启irqbalance前，所有软中断全部压在cpu0

开启irqbalance后，CPU分布(同一个用例的效果未抓图，此处切另一个用例的图)：

通过观察/proc/softirq文件，可以看到被沾满的CPU大部分是在等待网卡；判断增加网卡可能会提升数据表现；

• l数据观察原则：
  • • 数据观察点：由CPU/内存/网卡/磁盘等大项目进行观察；有异常的地方重复执行用例，观察具体实例数据；
    • 每次均应收集服务器性能指标数据，以备对比；
    • 数据采样：单个用例多次执行，如结果浮动不大，则采取中间值；如波动较大，找出原因后，给出区间；

测试结果

1、114字节的数据，读写比例4:1下性能数据:  ------源自开发估算

直连redis，单实例       10w/s
直连redis，单机(10实例)       35w/s
1接入机+1 redis机       40w/s
2接入机+1 redis机       62w/s

2、理论值114字节数据可以达到100W/S，实际只有62W左右； ------ 根据执行结果估算；

3、瓶颈在于两点：

• Proxy的内核负载不平均，软中断过高；已开启irqbalance，但还是不平均；
• Proxy的网卡流量限制；------ 暂无法解决；

其他说明：

l  每次修改实例数后，需要重新执行写入动作，让数据平均分布到各实例，否则在读取的时候不准确；部分读命令无法找到数据；

l  本次测试场景考虑比较简单，属于验证能力类的测试；比如未考虑网络影响（实际上主备实例是跨机房的，这里是同机房不同机器）

另外，发现直连比代理方式的bo/bi更多，未能找到多写入了什么东东。暂时未解决此处；

基于业务封装API进行Redis服务性能测试记录

标签：style   blog   http   ar   使用   sp   文件   on   数据   

原文地址：http://www.cnblogs.com/carterzhang/p/4133329.html