Twemproxy测试用例以及压测结果
来源:互联网 发布:网络大电影合作说明 编辑:程序博客网 时间:2024/06/07 06:55
1、前端使用 Twemproxy 做代理,后端的 Redis 数据能基本上根据 key 来进行比较均衡的分布。
后端一台 Redis 挂掉后,Twemproxy 能够自动摘除。恢复后,Twemproxy 能够自动识别、恢复并重新加入到 Redis 组中重新使用。
2、Redis 挂掉后,后端数据是否丢失依据 Redis 本身的策略配置,与 Twemproxy 基本无关。
如果要新增加一台 Redis,Twemproxy 需要重启才能生效;并且数据不会自动重新 Reblance,需要人工单独写脚本来实现。
3、如同时部署多个 Twemproxy,配置文件一致(测试配置为distribution:ketama,modula),则可以从任意一个读取,都可以正确读取 key对应的值。
4、多台 Twemproxy 配置一样,客户端分别连接多台 Twemproxy可以在一定条件下提高性能。根据 Server 数量,提高比例在 110-150%之间。
5、如原来已经有 2 个节点 Redis,后续有增加 2 个 Redis,则数据分布计算与原来的 Redis 分布无关,现有数据如果需要分布均匀的话,需要人工单独处理。
6、如果 Twemproxy 的后端节点数量发生变化,Twemproxy 相同算法的前提下,原来的数据必须重新处理分布,否则会存在找不到key值的情况。
测试方式:
1.后端 Redis 节点数量不变,不同 Twemproxy server 测试及多个同时运行测试结果如下:
从上面数据可以看出,单台最多也只能达到单个 Redis 的性能;2个节点运行性能增加大概110%左右。4个 server 运行,性能大概增加了123%,6个 server 接入运行160%。
2.前端使用1个 Twemproxy server,后端 Redis 数量分别为2,3,4,5,6来进行压力测试,看测试结果,测试数据如下:
从数据可以看出,后端节点数量与 Twemproxy 的性能基本无关,最大性能也就是单个 Redis 的性能。
- Twemproxy测试用例以及压测结果
- java8 日期time测试用例以及结果分析
- SQL存储过程测试(2)——创建测试用例以及测试结果存储
- SQL存储过程测试——创建测试用例以及测试结果存储
- twemproxy
- Twemproxy
- 关于scanf的疑惑以及测试结果
- openstack性能测试用例和测试结果
- 测试v_fork以及关闭标准输出后输出结果
- select和poll程序测试以及结果分析
- JMeter 测试过程中的响应断言以及断言结果
- Linux性能测试工具-UnixBench--安装以及结果分析
- Linux性能测试工具-UnixBench--安装以及结果分析
- 第十四讲、jmeter中的监听器以及测试结果分析
- net自动化测试之道API测试-存储测试用例执行结果
- 自动化测试-使用使用数据库存储测试用例和测试结果
- AOV补遗(测试用例及结果)
- Twemproxy源码分析之三:其进程以及时间模型
- 跟我学Kafka源码之Broker Server
- 数字化转型,金融行业的下一个引爆点
- 深入理解并发之CompareAndSet(CAS)
- 秒杀思路
- 跟我学Kafka源码之LogManager分析
- Twemproxy测试用例以及压测结果
- iOS点击状态栏回到顶部(一个控制器中包含多个scrollview,系统自带的回到顶部失效)
- Redis Lua脚本使用(资料备份)不是博客
- 【转】Java开发必会的Linux命令
- 性能测试工具curl-loader(linux)
- PHP面试题
- SEDA架构模型
- PHP入门学习笔记
- 为什么说Kafka使用磁盘比内存快