======2015-1-13=============
- 性能测试
- 设备:12core*2.0G /128GB
- 客户端数: 100
append:
- Value: 长度 50 字节
- DB_COUNT=1 7w/s CPU:800%
- DB_COUNT=24 11w/s CPU:1300%
- DB_COUNT=1024 11w/s CPU:1300%
- 设置默认1024, 30GB下每个进程30M,Major GC影响小
pipeline:
- *2: 20w/s CPU 1800%
- *5/*10: 30w/s CPU 2000%
memory:
-
1kw用户 * 10条
-
写入完后: 30GB 平均每条占用300字节 强制GC后->20GB
-
没有达到要求,基于c redis版本修改实现见:https://github.com/LittlePeng/redis
==================================== 增量消息存储按照会话存储初步方案实现:
- 将消息存储与进程中,使用redis协议
- 写入性能还不错,但CPU消耗偏高,但一条50字节的消息实际得消耗300字节,erlang实现对内存把控不太好做
总体看此方案并不太完美,不太好深入优化;考虑换用其他两个方案:
- 基于redis 修改
- 容易把控内存,CPU占用更低;
- 业务还是较为繁琐,有一定实现和维护成本
- 全部存储,读取时丢弃
- 将一个用户一周内全部消息都存储,取消200条上限
- 读取时再丢弃过长会话
- 比较高效,因为读比例很少
- 依然需要对使用redis或其他存储做修改,以方面自动维护一周数据