【问题标题】:RavenDB Deserialization seems slowRavenDB 反序列化似乎很慢
【发布时间】:2011-12-06 21:42:43
【问题描述】:

我一直在玩 RavenDB(内部版本 531),但我似乎无法获得正确的性能。

我有一个简单的课程

    public class Cat
    {
      public string Id {get; set;}
      public string Name {get; set;
    }

我随机创建了大约 200 只猫,并将它们放入 RavenDB。

但是当我去取一只猫时,通过

   session.Load<Cat>("cats/<GUID>");

大约需要 700 毫秒。

RavenDB 的调试窗口如下所示

    Request # 156: GET - **0 ms** - <default>-200-/docs/cats/<GUID>

它返回了正确的 Cat,但反序列化似乎需要很长时间。

我试图反序列化文件的输出,看看这是否真的是罪魁祸首,但我似乎不知道该怎么做。

想法?

编辑:我尝试只反序列化一个普通的旧 Cat 对象,它花了 100 毫秒。

Edit2:这是答案。

似乎有一些重要的启动成本。

如果我在第一个 Cat 之后获取任何其他 Cat,我的性能会显着提高 - 达到

因此你为什么不只使用一次获取进行基准测试。

【问题讨论】:

  • 请发表您对该主题的发现并接受您的回答,以便它可以帮助处于相同情况的其他人。

标签: performance ravendb


【解决方案1】:

这里可能会发生一些事情。

  1. 您在使用索引吗?
  2. 您之前是否使用该查询对 Document Store 进行过 -any- 调用?

一般是因为

  1. 对文档服务器的第一次客户端调用有一些初始设置命中。
  2. 可能需要索引索引 - 例如。动态索引。

更多细节...

当第一次在 RavenDB 文档存储中使用任何数据时......将需要一些索引。当执行查询并且没有使用(或猜测)索引时会发生这种情况。我认为第一次创建索引时也会发生这种情况.. 但我不是 100% 确定这一点。

所以一般来说,很多人首先只是尝试在没有索引的情况下查询文档存储。最初的第一次打击总是很昂贵。创建初始文档存储(在客户端)很昂贵..which is why it's suggested to be a Singleton。如果第一次执行该查询并且它是一个动态索引。那么必须创建该索引,编制索引,然后返回给客户端。

所以第一次击球需要一些初始的热身。

【讨论】:

  • 我正在使用动态索引进行查询,但是索引已经建立。性能问题是由于第一次命中 Document Store。
猜你喜欢
  • 2021-12-11
  • 1970-01-01
  • 1970-01-01
  • 2015-02-16
  • 1970-01-01
  • 1970-01-01
  • 2018-02-02
  • 2014-11-26
  • 2016-09-08
相关资源
最近更新 更多