aerospike性能测试

单节点测试：
[if !supportLists]l
[endif]测试环境配置
两个物理机 AB，A作为Server节点，B作为客户端节点，AB配置一致：24
CPU， 128G内存，SSD盘，万兆网卡；数据库配置项中，工作队列和网络线程（epoll）数量和CPU数量一致.
写入性能测试一
在key取值区间是【0-800M】，已有条数167M（value大小随机产生）,
磁盘数据100GB情况下，测试不同粒度的value的写入性能和延迟。表中，延迟的百分比含义依次为：小于1毫秒比例，大于1毫秒，大于2毫秒，大于4毫秒，大于8毫秒。。。（下面各个统计表延迟的值得含义均与之相同）
当value小于1KB之前，CPU基本跑满，
在usr 、sys、 si的时间比差不多各三分之一；大于等于1KB后，Server端50%左右的CPU时间都处于wa状态，即等待I/O状态。

Value 大小	10B	100B	1KB	10KB	100KB
写入Tps	37万	37万	35万	7万	1.2万
写入延迟	100%	100%	100%	88% 12% 2%	50% %50 20% 5%

写入性能测试二
key取值区间是【0-800M】，已有条数373M（value大小随机产生）,
磁盘数据320GB情况下，当value大小小于1KB之前，CPU无法跑满，在wa状态的比例大概20%；大于等于1KB后，Server端超过50%的CPU时间都处于wa状态，即等待I/O状态。

Value大小	10B	100B	1KB	10KB	100KB
写入Tps	25万	23万	17万	3万	0.8
写入延迟	97% 3%	97% 3%	%93 %7 %3 %1	80% 20% 12% 10 % 7% 6% 4%	14% 86% 60% 43% 32% 23% 1%

读写性能测试三
根据value大小的不同，设定固定的key的取值空间，每种size的value均预先插入取值空间全部的80%的key（value的大小是固定的），读写的速率统计如下，由于预先插入了较多的record，修改写操作较多，写入性能有明显降低。

Value 大小	10B	100B	1KB	10KB	100KB
写入区间	10GB	1GBMB	100MB	30MB	3MB
写入Tps	25万	17万	14万	2.5万	0.25万
写入延迟	100%	100%	100%	96%,4%,2%,2%,1%	29% 71% 56% 5%
读写50%	读16万，写14万	读写均为8万	均为5万	写2万，读4万	写0.15万 读1万
平均延迟	100%	100%	100%	99% 1%	40%，60%，35% 25%
只读	26万	16万	11万	9万	1.7万
延迟	99% 1%	100%	100%	99% 1%	66% 34%,16%,7%,3%

Partition迁移过程读写性能测试
[if !supportLists]l
[endif]测试环境配置：
三个物理机 ABC，AB作为Server节点，C作为客户端节点，AB配置一致：24
CPU， 128G内存，SSD盘，万兆网卡；C除了没有SSD盘外其他与之一致。
[if !supportLists]l
[endif]测试方案：
配置数据副本数为2，先启动A并写入部分数据，然后启动B，之后A开始迁移副本数据到B，此时C发起读写请求，测试吞吐和延迟。

已有数据80M条，磁盘空间100GB，迁移速率13
万tps下，写入的record的key取值区间
【0，1G】（修改写的比例为8%），读写速度如下表所示：
可以看出，写入性能有明显下降，但读取性能基本没有下降。

Value 大小	10B	100B	1KB	10KB	100KB
写入Tps	7万	7万	5万	2万	0.5万
写入延迟	93% 7% 3% 3% 2% 1% 1%	94% 6% 2% 1% 1% 1% 1%	93% 7% 3% 2% 1% 1% 1%	77% 23% 8% 4% 2% 2% 1%	9% 91% 88% 83% 74% 54% 35%
读取tps：29万，延迟均小于1毫秒

Record条数是500M，数据量是300GB,key取值区间是【0-8G】，每条record的大小是随机值，控制迁移速度是2万tps的情况下，写入速度如下所示。

Value 大小	10B	100B	1KB	10KB	100KB
写入Tps	15万	12万	8万	4.2万	0.8万
写入延迟	93% 7%	93% 7%	90% 10%	65% 35% 20% 15% 5%	3% 97% 88% 76% 60% 24%