7

我开始将一个简单的 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 行。查询很简单，返回一个具有 48 个字节大小的 12 个属性的对象。使用 fiddler 对 RavenDB 运行 WCAT 测试会在数据库机器上产生更高的利用率（相对于 SQL）和更少的页面。我尝试将 Raven 作为服务和 IIS 应用程序运行，但没有看到明显的差异。

编辑

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

来自 Appharbor 的结果

您可以在这里尝试（暂时）：

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

  2. 写入/保存：（197-312ms）*哇，保存时间很长*。要测试保存，只需创建一个新的“东西”并保存它。您可能希望至少执行两次，因为第一次通常会随着应用程序的升温而花费更长的时间。

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

有没有办法加快速度，或者这是可以预料的？

4

2 回答 2

3

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

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

RavenDB 身份验证和 401 响应。

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

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

  1. 全面测试它是否修复了我们在 RavenDB 服务器上看到的性能问题
  2. 调查和测试使用 UnsafeAuthenticatedConnectionSharing 和预身份验证的影响。
于 2012-04-23T20:21:20.880 回答
0

To summarize Ayende's response you're actually testing the summation of network latency and authentication chatter. As Joe pointed out there's ways you can optimize the authentication to be less chatty. This does however arguably reduce security, clearly Microsoft built security to be secure first and performance secondary. You as the user of RavenDB can choose if the default security model is too robust as it arguably is for protected server-to-server communication.

RavenDB is clearly defined to be READ orientated. 10-20x slower for writes than reads is entirely acceptable because writes are full ACID and transactional.

If write speed is your limiting factor with RavenDB you've likely not modeled transaction boundaries properly. That you are saving documents that are too similar to RDBMS table rows and not actually well modeled documents.

Edit: Reading your question again and looking into the background section, you explicitly define your test conditions to be an optimal scenario for SQL Server while being one of the least efficient methods for RavenDB. For data that size, that's almost certainly 1 document if it would be real world usage.

于 2012-05-21T20:51:33.327 回答