RavenDB—写入/保存性能缓慢

我开始将一个简单的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示例应用，并简单地将Miniprofiler添加到该解决方案中。Michael是Apharbor的一个很棒的家伙，如果你想看的话，你可以在这里下载代码

Appharbor的结果

您可以在此处尝试（目前）：

读取：（7-12ms，在100毫秒以上时有一些异常值）。
写入/保存：（197-312ms）*哇，保存时间太长了*。要测试保存，只需创建一个新的"thingy"并保存即可。您可能需要至少执行两次，因为随着应用程序的预热，第一次通常需要更长的时间。

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

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

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

第二，我们遇到了类似的问题。以下是关于谷歌群组的讨论链接，这可能是原因：

RavenDB身份验证和401响应。

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

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

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

为了总结Ayende的响应，您实际上是在测试网络延迟和身份验证聊天的总和。正如Joe所指出的，有一些方法可以优化身份验证，使其不那么健谈。然而，这确实降低了安全性，很明显，微软将安全性放在第一位，性能放在第二位。作为RavenDB的用户，您可以选择默认安全模型是否过于健壮，因为它可以说是受保护的服务器到服务器通信。

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

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

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

相关内容

最新更新

热门标签：