缓慢的写入/保存性能？
我开始将简单的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测试会在数据库计算机（vs SQL）上产生更高的利用率，并且页数会少得多。 我尝试将Raven作为服务运行并作为IIS应用程序运行，但没有看到明显的差异。
编辑
我想确保它不是a）我的一台机器或b）我创建的解决方案的问题。 因此，决定尝试使用Michael Friis创建的另一个解决方案： RavenDN示例应用程序在Appharbor上进行测试，并将Miniprofiler添加到该解决方案。 迈克尔是Apharbor的杰出人物之一，如果你想看，你可以在这里下载代码。
来自Appharbor的结果
你可以在这里尝试 （现在）：
阅读:( 7-12ms，在100 + ms处有几个异常值）。
写/保存：（197-312ms） * WOW很长时间可以保存* 。 要测试保存，只需创建一个新的“thingy”并保存。 您可能希望这样做至少两次，因为应用程序预热时通常需要更长的时间。
除非我们都做错了，否则RavenDB保存起来非常缓慢 - 大约比读取速度慢10-20倍。 鉴于它重新索引异步，这似乎很慢。
有什么方法可以加速或预期这种情况吗？
首先 - Ayende是RavenDB背后的“男人”（他写的）。 我不知道他为什么不解决这个问题，虽然即使在谷歌的团队中，他似乎也只是提出一些尖锐的问题，但很少回过头来提供完整的答案。 也许他正在努力让RavenHQ离开地面？！？
其次 - 我们遇到了类似的问题。 以下是可能导致Google群组讨论的链接：
RavenDB身份验证和401响应。
一个合理的问题可能是：“如果这些建议解决了这个问题，那么为什么RavenDB不以这种方式工作？” 或者至少提供有关如何获得体面的写作表现的文档。
我们玩了一段时间，在上面的线程中提出了一些建议，响应时间也得到了改善。 最后，我们转回到MySQL，因为它经过了充分的测试，我们很早就遇到了这个问题（幸运的是），这引起了我们可能遇到更多问题的担忧，最后，因为我们没有时间：
总结Ayende的回应，你实际上正在测试网络延迟和认证喋喋不休的总和。 正如Joe指出的那样，您可以优化身份验证以减少聊天。 然而，这确实降低了安全性，显然微软建立的安全性首先是安全的，而性能是次要的。 作为RavenDB的用户，您可以选择默认安全模型是否过于健壮，因为它可以说是用于受保护的服务器到服务器通信。
RavenDB明确定义为以读取为导向。 写入比读取慢10-20倍是完全可以接受的，因为写入是完整的ACID和事务性的。
如果写入速度是RavenDB的限制因素，那么您可能没有正确建立事务边界。 您保存的文档与RDBMS表格行过于相似，而且实际上没有很好的建模文档。
编辑：再次阅读您的问题，并查看背景部分，您明确定义您的测试条件是SQL Server的最佳方案，同时也是RavenDB最不高效的方法之一。 对于数据大小，如果它是真实世界的用法，那几乎肯定是1个文件。
链接地址: http://www.djcxy.com/p/10635.html