英文原文：

http://blog.mongodirector.com/how-to-benchmark-mongodb-with-ycsb/

当谈到系统性能特性，大多数DBaaS提供商提供他们预置系统的有限信息。的确，基于在这样一个系统下给定的大量参数的部署，很难准确的讨论云的实际吞吐量和延时。虚拟化环境、不可预测的负载、网络延时、不同地址位置只是考虑的一部分。

然而对于你的MongoDB部署的真实性能有一个公正的理解是个好注意：以至于你可以基于你的应用需求准确预置；以至于你可以真实的比较大量的DBaaS提供商，确保最实惠。

这篇博文是在你的MongoDB集群上运行一些基本的性能检测的入门。详细讲述如何配置和运行YCSB基准测试并解释了结果。灵感来自于当前的MongoDB博客关于MongoDB 3.0性能提高。

YCSB是一个流行的Java开源规范和由雅虎开发的程序套件，用于比较大量NoSQL数据库的相对性能。这些工作负载用于大量NoSQL数据库的比较研究。

部署YCSB

这部分和接下来的部分将会引导你，在你钟爱的DBaaS提供商系统上，一步步安装、配置和运行YCSB测试。

为了运行负载测试，你需要一个客户端机器，与你的MongoDB集群在相同的地理位置最好，可以避免网络延时。选择一个合适的配置运行多线程，恰当的加载你的MongoDB集群。该机器需要安装有当前版本的Java、Maven和git。

步骤：

• 如果Java、Maven或git还没有在你的系统上安装，安装他们。参照你的操作系统对应的可用文档。确保安装了与你的Java版本兼容的Maven版本。测试所有的依赖正常工作。例如：

• 正如Github页YCSB的建议，你可以wget下YCSB的tar压缩包。但是我们推荐从源文件构建。步骤已在YCSB的MongoDB README文档化。这将帮助我们之后对云提供商启用MongoDB验证。

• 注意：如果你的`mvn clean package`或`mvn clean install`命令失败，根据位于“mapkeeper”包的错误，在pom.xml的root层删除或注释“mapkeeper”条目的两个实例。查看这里Github问题获取更多信息。

• 一旦构建成功，我们现在准备运行YCSB测试！

启用验证

大多数MongoDB提供商默认提供MongoDB验证并无法禁用它。不幸的是，YCSB当前不支持MongoDB验证。客户端实现现在主要使用废弃的API调用。为了满足我们的需求，我们添加了一个新的MongoDB专属YCSB属性，'mongodb.auth'和几行代码支持它。这个修改非常简单并且在这里可以找到不同。默认MongoDB专属YCSB属性在这里列出。

再次使用mvn构建包，修改完成。参考上面部分关于如何使用Maven构建YCSB。

运行测试

YCSB wiki这部分详细列出了接下来的活动。我们将在这里简要描述下。

• 下一步是选择你要运行的负载类型。花时间阅读和理解YCSB wiki的核心负载部分。它们总结在这里：

  • 负载A：重更新负载：50/50%混合读/写

  • 负载B：读为主负载：95/5%混合读/写

  • 负载C：只读：100%读

  • 负载D：最新读负载：更多流量在当前插入

  • 负载E：短距离：短程查询

  • 负载F：读-修改-写：读、修改和更新存在的记录

• 显然个体工作负载可以使用核心属性调整。你可能想选择一个负载，调整属性匹配你应用程序的特性。例如，对比研究选择了大批有趣的“调整过的”负载。也参考了在第一部分提到的MongoDB博客。例如，对于我们的测试我们将采用负载A带有默认读/写比率。

• 选择操作的数量（属性“operationcount”）以致测试运行适当的时间。30分钟内完成测试不是系统一般性能的好的指示。

• 选择适当数量的YCSB运行的线程。这真的依赖于你的客户端机器有多好，你的MongoDB集群可以承受多少负载和你的实际应用多么有代表性。我们将对大量的线程运行基准测试。

• 运行负载阶段。选择一个接近你想运行的操作数量的记录数量（属性“recordcount”）来插入数据库。选择适当数量的线程以便插入不会花费很长时间。例如：

• • ‘load‘标记表名它是一个导入操作。

  • ‘s‘标记以10秒的间隔打印状态。

  • ‘recordcount‘被设置为1千万。

  • ‘threads‘设置客户端线程数量为16

  • ‘mongodb.auth‘是启用MongoDB验证的属性。

• 记得

  • 重定向标准输出到一个文件

  • 使用‘screen‘或一个等价的方法，以便当运行这些操作的时候你的会话不会丢失。

• 一旦数据导入阶段完成，你准备运行你的负载。例如：

• 使用大量的线程重复运行。记住重定向结果以便你之后可以比较它们。例如，我们用2、4、8、16和32个线程重复测试。

分析结果

这篇YCSB wiki页面的最后部分谈到了分析结果。最有趣的一些信息是整体吞吐量（Overall Throughput）和95/99%百分比延时（Percentile Latencies）。直到当收益变平和延时不可接受时，通常增加线程数量增加了吞吐量。例如，这张图描述了对一个我们要检测的测试系统，吞吐量和延时和线程数的对比。选择的负载是负载A和大约3百万操作。

Throughput/Latency vs #Threads

对于MongoDB服务器从负载的角度，从图中可以推断出16个线程也能是热点区域：超过了它，对于线程数呈指数增长，吞吐量的线是平的，而延时变得无法接受的大。

一些观点：

• 为了云上系统性能的更好的图片，自动化并重复这些测试应该在一天的不同点。我们注意到性能的特性会在这一天显著变化。

• 当比较两个潜在的DBaaS提供商，确保在相同的地理位置选择你的客户端机器和DBaaS集群。集群应该有类似的配置。也要记住在一天的不同时间运行测试。

接下来

这是一些我们需要研究的事情，因为我们在这个方面做了更多工作：

• 从多台机器并行运行负载：当尝试加载一个高容量的MongoDB集群，单一一台客户端机器无法满足。YCSB当前没有提供容易的方法并行从多台机器运行负载。然而可以手动完成。当尝试加载数据到一个大型集群时也是有用的。

• 数据集大小：数据库的大小相对MongoDB系统的内存将完全改变吞吐量/延时特性，对于大型数据集MongoDB只得命中磁盘。

• 个体记录的大小：当记录尺寸很大，尤其当它接近最大支持的尺寸时，对于性能特性是有趣的。这可能对主要做读-修改-回写操作（像负载F）的应用程序是关键性的。

• 不同的MongoDB驱动：因为我们当前正对比较两个不同的DBaaS提供商感兴趣，我们没有尝试使用更多有效的数据库驱动。显然使用最新和更有效的驱动可以获得更好的绝对数。对应用程序尝试抽取系统的最后价值是有趣的。这篇博文谈到了使用一个异步的MongoDB驱动通过YCSB的性能提升度量。

• 不同的检测工具：Sysbench对于MongoDB我们发现是有趣的。我们正在看其他的。