标签：二次 分片 一个人 xeon 吞吐量 批量 适合 softlayer 2.4
网上转载来的测试，仅供参考。原文地址：http://www.mongoing.com/benchmark_3_0
本测试过程使用了2类机器。
OS：centos6.5 64
Cpu：8核 E5 2407 2.4GHZ
RAM：16G
Disk：300G SATA*2 RAID 1
（点击查看大图）
同时连接数 op/s
6 15K
10 25K
17 40K
25 50K
50 50K
同时连接数 op/s
6 18K
10 25K
17 32K
25 38K
50 42K
同时连接数 op/s
6 23K
10 42K
17 50K
25 50K
50 50K
同时连接数 query/s insert/s
6 15K 15K
10 20K 20K
17 21K 21K
25 23K 23K
50 23K 23K
OS：centos6.5 64
Cpu：24核 E5 2403 1.8GHZ
RAM：64G
Disk：300G SSD RAID 10
（点击查看大图）
同时连接数 op/s
3 23K
4 50K
6 55K
8 65K
14 75K
20 85K
30 95K
35 100K
40 110K
45 150K
50 164K
同时连接数 op/s
3 14K
6 23K
15 44K
20 63K
25 93K
35 130K
40 140K
45 140K
50 150K
同时连接数 op/s
3 10K
6 41K
15 84K
20 120K
25 140K
35 180K
40 190K
45 193K
50 195K
同时连接数 query/s insert/s
3 10K 10K
6 31K 31K
12 44K 44K
25 60K 60K
35 75K 75K
50 75K 75K
下面在机器B上测试内存不足装下所有数据（只能装下index/index都无法全部装下）的情况
内存装下所有数据：
同时连接数 op/s
3 20K
5 40K
8 58K
12 80K
15 90K
22 130K
27 170K
35 180K
50 195K
内存仅装得下index：
同时连接数 op/s
3 8K
5 10K
8 16K
12 20K
15 25K
22 32K
27 40K
35 48K
50 57K
内存连index都无法全部放下：
同时连接数 op/s
3 3.4K
5 4.5K
8 9.3K
12 11K
15 14K
22 20K
27 24K
35 25K
50 34K
（点击查看大图）
索引全在内存中：
cache:data为4：10
索引不全在内存中
cache:data为1：10
mongodb官方的报告：
http://www.mongoing.com/archives/862
前言:
MongoDB 3.0的主要侧重点是提高性能，尤其是写性能和对硬件资源的利用率 。为了展示我们在3.0 中取得的成果和如何来应用这些新的改善，我们接下来将发布一系列博客来比较MongoDB 2.6和3.0的性能。
就像所有的基准测试一样，这些测试结果不一定适用于你的场景。 MongoDB的使用场景是多种多样的，采用那种能够反映你应用程序需求和你将要用来部署的硬件的性能测试是至关重要的。正因如此，目前并没有一个"标准的"测试程序可以告诉你哪个技术是最适合你的应用程序 。只有你的需求，你的数据，你的基础设施可以告诉你你所需要知道的。
为了帮助我们衡量性能，我们已经与社区合作采用了上百种不同的测试。这些测试反映了用户所开发的多种多样的应用程序，和用来部署这些应用的不断衍变的环境。
YCSB被一些机构用来作为对几个不同数据库的性能测试的一个工具。YCSB功能是相当有限的，并不一定能够告诉你所有你想了解的关于你应用程序性能方面的信息。当然，YCSB还是相当流行的，并且MongoDB和其他一些数据库系统的用户也对此比较熟悉。 在这篇文章内我们会比较MongoDB2.6和3.0的YCSB测试结果。
并发量：
在YCSB测试中，MongoDB3.0在多线程、批量插入场景下较之于MongoDB2.6有大约7倍的增长。我们应该期待这种测试场景有最大的改进，因为这是100%写操作，而WiredTiger的文档级 并发性控制对在多核处理器服务器上的多线程测试场景最有帮助 。
第二次测试比较了两个系统上 95%读取和5%更新的场景。这里我们看到WiredTiger 有4倍多的吞吐量。相比于刚才的纯插入场景，这次的性能提升没有那么显著，因为写操作只占所有操作的5%。在MongoDB2.6中，并发控制是在数据库级别，而且写会阻塞读操作，从而降低总体的并发量。通过这次测试，我们看到MongoDB 3.0更加细粒的并发性控制明显提高了总并发量。
最后，对于读写操作平衡的场景，我们看到 MongoDB3.0有6倍的并发率。这比我们刚才看到的95%读 的4倍提高要好一些，因为这里有更多的写操作。
响应延迟：
在性能测试中仅仅监测并发量是不够的，我们还要考虑操作的响应延迟 。对许多操作的响应延迟做一个平均得来的平均响应延迟值不是一个最好的度量指标。对于想要系统有持续良好、低延时体验的开发者来说，他们更关注在这个系统中效能最低的操作。 高延时查询通常用95th和99th百分位数来衡量 – 95th 百分位数表示这个数值（响应延迟）比95%的其他操作都要糟糕（慢）。（有人可能会觉得这种衡量不够准确： 因为很多网页请求会使用几百个数据库操作， 那么很可能绝大部分用户都会经历到这些99th百分位数的慢响应延迟 ）
在读操作响应延迟上我们看到在MongoDB2.6和MongoDB3.0之间的差别是非常微小的，读操作响应延迟很稳定的保持在1ms或者更少的数值内。然而更新操作响应延迟则有相当大的区别 。
在这里我们通过读密集型的工作负荷来比较更新响应延迟的95th和99th百分位数 。在MongoDB3.0中更新延时显著改善了，在95th和99th百分位数中几乎减少了90%。这很重要，提高并发量不应该以更长的延时为代价，因为这将最终降低应用程序 的用户体验。
在平衡的工作负荷下，更新延迟仍然保持在较低的水平 。在95th百分位数，MongoDB3.0的更新延迟比MongoDB2.6几乎低90%，而99th百分位数则低80% 。这些改善可以给用户带来更好的使用体验，更加可预测的性能。
我们相信这些针对并发量和响应延迟的测试证明了MongoDB在写性能上有了显著的提高。
小改变产生大影响：
在接下来的博客中我们将描述可以对MongoDB性能产生大影响的一些小改变。作为一个预览，我们来看一个人们经常忽略的因素。
提供充足的客户端能力：
YCSB的默认配置只使用一个线程。使用一个单线程，无论是哪个数据库你的测试结果都会很可怜 。 不要使用单线程基准测试除非你的应用程序运行单线程。单线程测试仅仅测量响应时间，不能测试并发量，而容量规划对两个因素都要考虑到。
大多数数据库都是为多线程客户端设计的 。通过逐步增加线程数来找到最佳的数量 – 增加更多线程直到你发现并发率停止上升或者响应时间在增加。
考虑为YCSB运行多个客户端服务器。一个单一客户端可能无法产生充足的压力来测试系统的容量。不幸的是，YCSB没有让使用多个客户端变的简单，你必须手动去协调多个客户端的开始和停止，而且你必须自己去综合各个客户端的测试结果。
当使用分片的时候，每1，2个分片使用一个mongos，并且每一个mongos要使用一个YCSB客户端。太多客户端进程可能会导致系统崩溃，开始会导致响应延迟增加，然而最终会导致CPU崩溃。有时候你需要去控制客户端的请求量。
寻找在响应延迟和并发量中正确的平衡点是任何性能调优的一个重要组成部分。通过监测延时和并发量，并且通过一系列测试增加线程量，你可以在延时和并发量两者之间确定明确的关系，并在一个给定工作负荷的情况下计算出最佳线程数。
基于这些测试结果我们观察到以下两点：
1、 所有操作的99th百分位数直到16线程为止都少于1ms。当多于16线程，响应延迟开始增加。
2、 并发量从1增加到64线程时会不断增长。在64线程之后，增加线程数不再提高并发量，但是响应延迟却在增加。
基于这些，应用程序的最佳线程数在16和64之间，且取决于我们更希望降低延迟还是提高并发量。在64线程时，延时看起来依旧很好：99th百分位数的读取少于1ms， 99th百分位数的写少于4ms。与此同时，并发量高于13万/秒
YCSB测试配置
我们测试了许多不同的配置来确定并发量和响应延迟之间的最佳平衡点。
在这些测试中，我们使用了3千万的文档和3千万的操作。文档包含一个100字节的字段（总共151字节） 并选择Zipfian作为读操作选记录方式。 我们通过逐步增加线程量直到95th和99th百分位数延时开始增加而并发量停止增加的时候确定了最佳线程数，这里发布的结果就是基于这个最佳线程数的测试。
所有测试使用了复制集，开启了恢复日志（Journal），服务器环境参照了我们的最佳实践来配置。我们始终建议在生产环境要使用复制集。
YCSB客户端在一个专门的服务器上运行。每一个复制集成员也在一个专门的服务器上运行。所有服务器都是具有下列规格的Softlayer 裸机：
1、CPU: 2x Deca Core Xeon 2690 V2 – 3.00GHz (Ivy Bridge) – 2 x 25MB cache
2、 RAM: 128 GB Registered DDR3 1333
3、 Storage: 2x 960GB SSD drives, SATA Disk Controller
4、 Network: 10 Gbps
5、 Ubuntu 14.10 (64 bit)
6、 MongoDB Versions: MongoDB 2.6.7; MongoDB 3.0.1
标签：二次 分片 一个人 xeon 吞吐量 批量 适合 softlayer 2.4
原文地址：http://www.cnblogs.com/xiaolang8762400/p/7261135.html
