RavenDB - 写入/保存性能慢？

Question

我开始将一个简单的 ASP.NET MVC Web 应用程序从 SQL 移植到 RavenDB。我注意到 SQL 上的页面比 RavenDB 上的更快。

使用 Miniprofiler 向下钻取，罪魁祸首似乎是执行所需的时间：session.SaveChanges (150-220ms)。 RavenDB 中保存的代码如下所示：

var btime = new TimeData() { Time1 = DateTime.Now, TheDay = new DateTime(2012, 4, 3), UserId = 76 };
session.Store(btime);
session.SaveChanges();

身份验证模式：当 RavenDB 作为服务运行时，我假设它使用“Windows 身份验证”。当部署为 IIS 应用程序时，我只使用了默认值——即“Windows 身份验证”。

背景：数据库机器与我作为 Web 服务器的开发机器是分开的。数据库在同一台数据库机器上运行。测试数据非常小——比如 100 行。查询很简单，返回一个具有 12 个属性、大小为 48 字节的对象。使用 fiddler 对 RavenDB 运行 WCAT 测试会在数据库机器上产生更高的利用率（相对于 SQL）和更少的页面。我尝试将 Raven 作为服务和 IIS 应用程序运行，但没有发现明显差异。

---

编辑

我想确保 a) 我的一台机器或 b) 我创建的解决方案没有问题。因此，决定尝试使用 Michael Friis 创建的另一个解决方案在 Appharbor 上对其进行测试：RavenDN sample app 并将 Miniprofiler 添加到该解决方案中。 Michael 是 Aphabor 的优秀员工之一，如果您想查看，可以下载代码 here。

Appharbor 的结果

您可以try it here（目前）：

1. 读取：（7-12ms，在 100+ms 时有一些异常值）。

2. 写入/保存：(197-312ms) * 哇，保存时间太长了 *。要测试保存，只需 create a new "thingy" 并保存即可。您可能需要至少执行两次，因为随着应用程序的升温，第一次通常需要更长的时间。

除非我们都做错了什么，否则 RavenDB 的保存速度非常慢 - 保存速度比读取速度慢大约 10-20 倍。鉴于它是异步重新索引，这似乎很慢。

有没有办法加快速度，或者这是意料之中的？

Answer 1

首先 - Ayende 是 RavenDB 背后的“人”（他写的）。我不知道他为什么不解决这个问题，尽管即使在谷歌小组中，他似乎也曾插话过一些尖锐的问题，但很少回来提供完整的答案。也许他正在努力让 RavenHQ 起飞？！？

第二 - 我们遇到了类似的问题。下面是关于可能是原因的 Google 网上论坛讨论的链接：

RavenDB Authentication and 401 Response.

一个合理的问题可能是：“如果这些建议解决了问题，为什么 RavenDB 不能以这种方式开箱即用？”或者至少提供有关如何获得良好写入性能的文档。

我们在上面的线程中提出的建议玩了一段时间，响应时间确实有所改善。最后，我们切换回 MySQL，因为它经过了良好的测试，我们很早就遇到了这个问题（幸运的是），这引起了我们可能会遇到更多问题的担忧，最后，因为我们没有时间：

1. 全面测试它是否解决了我们在 RavenDB 服务器上看到的性能问题
2. 调查和测试使用 UnsafeAuthenticatedConnectionSharing 和预身份验证的影响。

Answer 2

总结Ayende's response，您实际上是在测试网络延迟和身份验证聊天的总和。正如乔指出的那样，您可以通过多种方式优化身份验证以减少闲聊。然而，这确实会降低安全性，显然微软将安全性构建为安全第一，性能第二。作为 RavenDB 的用户，您可以选择默认安全模型是否过于健壮，因为它可以说是用于受保护的服务器到服务器通信。

RavenDB 被明确定义为面向读取。写入比读取慢 10-20 倍是完全可以接受的，因为写入是完整的 ACID 和事务性的。

如果写入速度是您使用 RavenDB 的限制因素，您可能没有正确建模事务边界。您正在保存与 RDBMS 表行过于相似的文档，而不是实际上建模良好的文档。

编辑：再次阅读您的问题并查看背景部分，您明确将测试条件定义为 SQL Server 的最佳方案，同时是 RavenDB 效率最低的方法之一。对于这种大小的数据，如果在现实世界中使用，那几乎可以肯定是 1 个文档。