Azure DocumentDB上的性能降低

And*_*sen 19 .net c# azure azure-cosmosdb

我目前面临来自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();
}
Run Code Online (Sandbox Code Playgroud)

要实例化客户端,我使用以下代码:

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

我从中获取的响应时间Stopwatch在360ms到1200ms之间,以返回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
Run Code Online (Sandbox Code Playgroud)

And*_*Liu 22

更新以反映最新的服务更改( 2017年1月22日): DocumentDB保证数据库端的SLA读取延迟<10 ms,p99写入延迟<15 ms.以下提示仍适用于使用SDK实现低延迟读取**

已更新以反映最新的服务更改(2016年6月14日):在通过用户定义的ID使用路由时,无需缓存自链接.还添加了一些提示.**

DocumentDB存储分区本身的读取通常小于1毫秒; 而瓶颈通常是应用程序和数据库之间的网络延迟.因此,最好让应用程序在与数据库相同的数据中心中运行.

以下是有关SDK使用的一些常规提示:

提示#1:在应用程序的生命周期内使用单个DocumentDB客户端

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

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

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

Document document = await client.ReadDocumentAsync("/dbs/1234/colls/1234354/docs/2332435465");
Run Code Online (Sandbox Code Playgroud)

话虽如此,应用程序可能无法始终使用文档的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;
                }
           }
Run Code Online (Sandbox Code Playgroud)

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

使用读取馈送功能(即ReadDocumentFeedAsync)执行批量读取文档时或发出DocumentDB SQL查询时,如果结果集太大,则会以分段方式返回结果.默认情况下,结果以100个项目或1 MB的块为单位返回,以先达到的限制为准.

为了减少检索所有适用结果所需的网络往返次数,您可以使用x-ms-max-item-count请求标头将页面大小增加到1000.如果您只需要显示几个结果,例如,如果您的用户界面或应用程序API一次只返回十个结果,您还可以将页面大小减小到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 });
Run Code Online (Sandbox Code Playgroud)

更多提示(2016年6月14日):

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

有关更多性能提示,请查看此博客文章.

  • 为什么技巧2被划掉了? (2认同)