CL LOCAL_QUORUM 为了保证用例读入的高一致性，这次我们测试了运行于LOCAL_QUORUM CL上吞吐量大于每秒百万次写入的用例。每秒100万次写入吞吐量平均延迟低于6毫秒，第95百分位为17毫秒 
每个客户节点都运行如下Cassandra Stress命令： cassandra-stress -d [list of C* IPs] -t 120 -r -p 7102 -e LOCAL_QUORUM -n 1000000000 -k -f [path to log] -o INSERT
综合测试——10%写入90%读入 每秒100万次写入只是一个醒目的标题，大多数应用程序都是读写混合的。在对Netflix主要应用程序调研之后，我决定做一个10%写入90%读入的综合测试，这一混合测试占用总线程的10%用于写入90%用于读取。这虽然不是实际应用程序的真实复现，但也能很好的测量数据拥塞时集群吞吐量及延迟
CL One 使用CL One配备时，C*实现了最高的吞吐量及可用性，开发人员需要接受其结果的一致性，并模仿这一范例设计他们的应用程序。 - 写入吞吐量大于每秒20万次写入，平均延迟大约为1.25毫秒，第95%百分位为2.5毫秒。
- 读出吞吐量大约为每秒90万次读出，平均延迟2毫秒，第95%百分位为7.5毫秒。
每个客户节点都运行如下Cassandra Stress命令： cassandra-stress -d $cCassList -t 30 -r -p 7102 -e LOCAL_QUORUM -n 1000000000 -k -f /data/stressor/stressor.log -o INSERT<br>cassandra-stress -d $cCassList -t 270 -r -p 7102 -e LOCAL_QUORUM -n 1000000000 -k -f /data/stressor/stressor.log -o READ
CL LOCAL_QUORUM 大多数用C*开发的应用程序都将默认为CL Quorum读写，这为其相关开发人员进入分布式数据库系统提供了机会，也避免了解决应用程序最终一致性的难题。 - 写入吞吐量小于每秒20万次写入，平均延迟大约为1.75毫秒，第95%百分位为20毫秒。
- 读出吞吐量大约为每秒60万次读出，平均延迟3.4毫秒，第95%百分位为35毫秒。
| 
