AWS 上的 FIWARE Orion/MongoDB 性能

Question

我似乎在试图获得接近文档中所述性能的任何地方时遇到了真正的问题（约 700 - 2000 tps，VM 为：2 个 vCPU 4GB RAM）。我已经在本地虚拟机、本地机器和一些 AWS 虚拟机上进行了尝试，但我无法接近。 - 我在 AWS VM 上达到的最大值是 80 tps。

我尝试更改 orion 的 -dbPoolSize 和 -reqPoolSize 并使用 ulimit 将其设置为 MongoDB 建议的值 - 但我所做的所有更改似乎都没有让我接近。

我已经按照文档中的建议在 _id.id、_id.type 和 _id.servicePath 上设置了索引 - 后者让我从 40 tps 增加到 80 tps。

我应该将 Orion 或 Mongo 的任何配置选项设置为远离默认设置，这会让我更接近吗？还有其他性能提示吗？文档中指向测试脚本的链接无效，因此我无法查看示例。

我已经使用 Node.js 创建了自己的测试脚本，并且我已经使用可变数量的并发连接和 1 到 2 个负载注入器测试了更新和查询。

从“顶部”的输出来看，负载来自 Mongo，因为它几乎耗尽了 CPU，但向 VM 添加更多内核并不会改变统计数据。虚拟机有 7.5GB 或 15GB 的 RAM，所以 mongo 应该能够将所有数据放入内存中以获得极快的性能？

我已经使用 mongostat 看到从 orion 到 mongo 的连接随着 -dbPoolSize 选项的变化而变化，但这并没有产生更好的性能。

您能提供的任何帮助将不胜感激。

我曾尝试将 CentOS 6.5 和 6.7 与 Orion 0.25 和 0.26 以及 MongoDB 2.6 与约 500,000 个实体一起使用

我的测试脚本和数据是on GitHub

到目前为止，我只在没有订阅的情况下进行了测试，但我已经准备好使用订阅进行测试的脚本 - 但我想在添加订阅之前获得一个好的基线。

我的数据是围绕英国国家/地区的停车位及其区域及其外代码（邮政编码的第一部分）建模的。这是使用 servicePaths 将它们拆分为 outcode 中的停车场。

这是gist with the requests and mongo shell output

Answer 1

性能是一个复杂的话题，取决于许多因素（Orion 和 MongoDB 的部署设置、Orion 和 MongoDB 的启动配置、托管进程的系统中的硬件配置文件、网络通信、虚拟化情况下的过度配置级别、注入负载等）所以没有任何通用的答案来处理这类问题。不过，我会尝试提供一些提示和建议，希望对您有所帮助。

关于版本，建议使用 Orion 0.26.0（或 0.26.1）而不是 0.25.0。我们在 Orion 0.26.0 中包含了与性能相关的 lot of improvements。关于MongoDB，我们也发现了3.0 could be much better than 2.6，特别是在更新密集的场景中。

话虽如此，首先你应该找到瓶颈。执行此操作的有用工具是 top、mongostat 和 mongotop。它可以是 Orion、MongoDB 或连接它们的网络。如果瓶颈是 CB，则可能是this document may help 中提供的性能调整提示。 MongoDB 中的慢查询信息也可能指向 Orion 的瓶颈。如果瓶颈是 MongoDB，考虑到您拥有的大量实体（500,000）也许您应该考虑实现sharding。如果瓶颈是网络，托管 Orion 和 MongoDB 可能会有所帮助。

最后，您还可以尝试一些方法来更深入地了解问题：

• 在 AWS 之外运行一些测试（即本地虚拟机）以进行比较。我对 AWS 中的过度配置政策了解不多，但根据我之前与其他云提供商的经验，VM 过度配置（特别是如果它随时间变化）可能会影响性能。
• 分析性能是否与实体数量有关。例如。使用 500、5,000、50,000 和 500,000 个实体运行测试，并获得每种情况下的性能数据。
• 分析性能是否与 servicePath 的使用有关，例如将所有 500,000 个实体放在默认服务路径 / 中（将 servicePath 的当前内容移动到另一个位置，例如实体属性或实体 ID 字符串的一部分）并测试。目前 Orion 使用正则表达式来过滤 servicePath，这可能会很慢。