0-环境
1-写性能
2-读性能
3-灾备
---------0.环境---------
共四台服务器:29.mzhen.cn - 32.mzhen.cn
Cassandra使用DHT结构，不存在主从服务器区别。
但是Cassandra设置了一台机器为每台机器分配Hash范围，称为Seed机器，在本次测试中Seed机器设置为29.mzhen.cn
机器配置：16*Xeon 2.27, 16GB, 2TB * 2(7200k, raid5, XFS 文件系统）, 1Gbps
Java虚拟机的配置为，64位，Xms512MB, Heap 8GB
测试发现CPU利用率在700%/1600%左右，内存利用率较高，虚拟内存使用在50GB-100GB，物理内存使用在4-5GB
测试数据结构，64B key + (5B col) * 3
---------1.写性能---------
1.1-写程序
c_benchmark/load-data.cpp
使用多线程/批量写的方式，且把写入进程分布在4台机器上。
1.2-测试结果
多线程，1,000,000key/150s, (6667key/s)
磁盘IO显示写入速度较慢，为5MB/s/每台机器，最大可以达到10MB/s但不稳定。
通过nodetool -h 29.mzhen.cn ring分析写入结果，得到Cassandra的实际写入速度为6-15MB/s/集群
通过iptraf -g分析网络速度，得到速度为50-100Mbps，约12.5MB/s，基本和Cassandra报告的数据符合
另外，通过添加机器可以提高写入速度，但并非线性关系。
1.3-异常情况
写入过程中会出现错误，提示Cassandra服务器Unavaliable，写程序会异常退出。
在邮件列表中求助，得知这是由于写入速度过快，系统难以响应导致的。因此可以认为1.2中报告的写入速度是最大速度。
---------2.读性能---------
2.1-读程序
c_benchmark/scan-data.cpp
2.2-测试结果
顺序读，单进程，100,000key/45s (2222key/s)
顺序读，多进程，400,000key/45s (8888key/s)
多进程读取时，进程均匀的分布在测试机器上。增加到3个进程时仍然保持在45s，增加到4个进程时时间开始小幅增加。
可见使用4个进程能够完全发挥系统能力。
随机读，单进程，70%命中率，10,000key/15s (666key/s)
随机读，多进程，70%命中率，40,000key/15s (2667key/s)
和顺序读基本一致。
2.3-读写同时进行-相同表
顺序读速度，单进程，70%命中率，10,000key/18s (555key/s)
写速度，多线程，1,000,000key/150s, (6667key/s)，和1.2节结果一致。
可以认为Cassandra优先处理写请求。
2.4-读写同时进行-不同表
和2.3节测试结果一致。Cassandra将数据存储在离散的文件中，可以认为处理不同表时性能基本不变。
2.5-异常情况
无
---------3.灾备---------
3.1-写过程灾备
写程序需要指定响应机器，设为A。停掉集群中除A外的任意机器，写程序可以继续运行。
有时会报告某台服务器Unavaliable错误，写程序抛出异常并退出，但重启写程序后可以继续
停掉A，写程序报告如下错误并退出。
terminate called after throwing an instance of 'apache::thrift::transport::TTransportException'
3.2-读过程灾备
和3.1节完全相同。
3.3-数据受损
停掉某台机器的Cassandra进程，并删除所有数据文件。重新启动进程后，日志中没有出错信息
用nodetool -h localhost ring检查数据量，得到本地数据量被清空
但尝试读取数据文件，集群仍能返回结果。
尝试用nodetool -h localhost loadbalanace/repair修复，均未能使数据恢复
注意，
数据恢复办法参见3.4节
3.4-元数据受损
停掉进程后删除所有的元数据文件。重启进程得到如下提示，
INFO [main] 2010-06-07 13:26:12,969 StorageService.java (line 378) Joining: getting bootstrap token
Boostrap过程结束后(这个过程很长，且期间访问数据会出现Unavaliable异常)，该机器的元数据和用户数据都得到恢复。
