Azure DocumentDB 性能缓慢

Question

我目前正面临 Azure DocumentDB 的响应时间很慢（第一次尝试）。

集合中有 31 个对象，我将获取这些对象并返回给调用者。我使用的代码是这样的：

public async Task<List<dynamic>> Get(string collectionName = null)
{
    // Lookup from Dictionary, takes literally no time
    var collection = await GetCollectionAsync(collectionName);

    var sw = Stopwatch.StartNew();

    var query = await
        _client.CreateDocumentQuery(collection.DocumentsLink, 
            new FeedOptions { MaxItemCount = 1000 })
            .AsDocumentQuery()
            .ExecuteNextAsync();

    Trace.WriteLine($"Get documents: {sw.ElapsedMilliseconds} ms");

    return query.ToList();
}

为了实例化客户端，我使用以下代码：

_client = new DocumentClient(new Uri(endpoint), authKey, new ConnectionPolicy
{
    ConnectionMode = ConnectionMode.Direct,
    ConnectionProtocol = Protocol.Tcp
});

我从Stopwatch 得到的响应时间在 360 毫秒到 1200 毫秒之间，以返回 31 个对象。对我来说，这相当很慢。如果没有自定义 ConnectionPolicy，平均响应时间约为 950 毫秒。

我在这里做错了吗？是否有可能以某种方式加快这些请求的速度？

这是 Trace 的输出，打印出秒表的经过时间：

Get documents: 1984 ms
Get documents: 1252 ms
Get documents: 1246 ms
Get documents: 359 ms
Get documents: 356 ms
Get documents: 356 ms
Get documents: 351 ms
Get documents: 1248 ms
Get documents: 1314 ms
Get documents: 1250 ms

Answer 1

已更新以反映最新的服务更改（2017 年 1 月 22 日）： DocumentDB 保证 p99 读取延迟

已更新以反映最新的服务更改（2016 年 6 月 14 日）：通过用户定义的 id 使用路由时无需缓存自链接。还添加了一些提示。**

DocumentDB 存储分区本身的读取通常需要

以下是一些关于 SDK 使用的一般提示：

提示 #1：在应用程序的整个生命周期中使用单例 DocumentDB 客户端

请注意，每个 DocumentClient 实例都是线程安全的，并且在直接模式下运行时执行高效的连接管理和地址缓存。为了通过 DocumentClient 实现高效的连接管理和更好的性能，建议在应用程序的整个生命周期内为每个 AppDomain 使用一个 DocumentClient 实例。

提示 #2：缓存文档和集合 SelfLink 以降低读取延迟

在 Azure DocumentDB 中，每个文档都有一个系统生成的 selfLink。这些 selfLink 保证在文档的整个生命周期内是唯一且不可变的。使用 selfLink 读取单个文档是获取单个文档的最有效方式。由于 selfLink 的不变性，您应该尽可能缓存 selfLink 以获得最佳读取性能。

Document document = await client.ReadDocumentAsync("/dbs/1234/colls/1234354/docs/2332435465");

话虽如此，应用程序可能并不总是可以使用文档的 selfLink 进行读取场景；在这种情况下，检索文档的下一个最有效方法是通过文档的用户提供的 Id 属性进行查询。例如：

IDocumentQuery<Document> query = (from doc in client.CreateDocumentQuery(colSelfLink) where doc.Id == "myId" select document).AsDocumentQuery(); 
            Document myDocument = null;
            while (query.HasMoreResults)
            {
                FeedResponse<Document> res = await query.ExecuteNextAsync<Document>();
                if (res.Count != 0) {
                    myDocument = res.Single();
                    break;
                }
           }

提示 #3：调整查询/读取提要的页面大小以获得更好的性能

使用读取提要功能（即 ReadDocumentFeedAsync）执行批量读取文档或发出 DocumentDB SQL 查询时，如果结果集太大，则以分段方式返回结果。默认情况下，结果以 100 项或 1 MB 的块的形式返回，以先达到的限制为准。

为了减少检索所有适用结果所需的网络往返次数，您可以使用 x-ms-max-item-count 请求标头将页面大小增加到最多 1000。如果您需要显示只有少数结果，例如，如果您的用户界面或应用程序 API 一次只返回 10 个结果，您还可以将页面大小减小到 10，以减少读取和查询消耗的吞吐量。

您还可以使用可用的 DocumentDB SDK 设置页面大小。例如：

IQueryable<dynamic> authorResults =
client.CreateDocumentQuery(documentCollection.SelfLink, "SELECT p.Author FROM Pages p WHERE p.Title = 'About Seattle'", new FeedOptions { MaxItemCount = 1000 });

更多提示（2016 年 6 月 14 日）：

• 使用点读取（例如读取文档而不是查询文档）按 id 进行查找
• 将 DocumentDB 客户端（使用 ConnectionPolicy）配置为通过网关使用直接连接
• 将客户端配置在与数据库相同的 Azure 区域中
• 调用 OpenAsync() 以防止更高的首次调用延迟
• 您可以通过在可查询对象上调用 ToString() 来调试 LINQ 查询，以查看通过网络发送的 SQL 查询

如需更多性能提示，请查看blog post。