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）我创建的解决方案不是问题。因此，决定尝试在 Appharbor 上使用Michael Friis创建的另一个解决方案进行测试： RavenDN sample app ，只需将Miniprofiler添加到该解决方案中。迈克尔是Apharbor的一个很棒的人，你可以下载代码 here ，如果你想看看它。

Appharbor的结果

您可以 try it here （暂时）：

阅读：（7-12毫秒，少数异常值为100 + ms）。
写入/保存：（197-312ms） * WOW需要很长时间才能保存* 。要测试保存，只需 create a new "thingy" 并保存即可。你可能想要至少两次这样做，因为第一个通常需要更长时间，因为应用程序预热。

除非我们都做错了，否则RavenDB的保存速度非常慢 - 保存速度比读取慢10-20倍。鉴于它以异步方式重新索引，这看起来非常缓慢。

有没有办法加快速度或预期？

Answer 1

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

第二 - 我们遇到了类似的问题。以下是可能导致Google网上论坛讨论的链接：

RavenDB Authentication and 401 Response

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

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

完全测试它是否修复了我们在RavenDB服务器上看到的性能问题
调查并测试使用UnsafeAuthenticatedConnectionSharing＆amp;预认证。

Answer 2

总结Ayende's response您实际上是在测试网络延迟和身份验证聊天的总和。正如乔指出的那样，您可以通过各种方式优化身份验证，使其不那么繁琐。然而，这确实可以降低安全性，显然微软建立的安全性首先是安全的，性能是次要的。您作为RavenDB的用户可以选择默认安全模型是否过于健壮，因为它可以说是受保护的服务器到服务器通信。

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

如果写入速度是RavenDB的限制因素，则可能无法正确建模事务边界。您要保存的文档与RDBMS表行太相似，而不是实际建模良好的文档。

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

RavenDB - 写入/保存性能慢？

2 个答案: