DocumentDB性能问题 [英] DocumentDB performance issues

问题描述

从本地计算机上C#代码的DocumentDB查询运行时，一个简单的DocumentDB查询平均大约需要0.5秒.另一个示例，获得对文档集合的引用平均大约需要0.7秒.这是可以预期的吗?下面是我用于检查集合是否存在的代码，这很简单-但是有什么方法可以改善不良性能吗?

When running from DocumentDB queries from C# code on my local computer a simple DocumentDB query takes about 0.5 seconds in average. Another example, getting a reference to a document collection takes about 0.7 seconds in average. Is this to be expected? Below is my code for checking if a collection exists, it is pretty straight forward - but is there any way of improving the bad performance?

// Create a new instance of the DocumentClient
var client = new DocumentClient(new Uri(EndpointUrl), AuthorizationKey);

// Get the database with the id=FamilyRegistry
var database = client.CreateDatabaseQuery().Where(db => db.Id == "FamilyRegistry").AsEnumerable().FirstOrDefault();

var stopWatch = new Stopwatch();
stopWatch.Start();

// Get the document collection with the id=FamilyCollection
var documentCollection = client.CreateDocumentCollectionQuery("dbs/" 
    + database.Id).Where(c => c.Id == "FamilyCollection").AsEnumerable().FirstOrDefault();

stopWatch.Stop();

// Get the elapsed time as a TimeSpan value.
var ts = stopWatch.Elapsed;

// Format and display the TimeSpan value.
var elapsedTime = String.Format("{0:00} seconds, {1:00} milliseconds",
    ts.Seconds,
    ts.Milliseconds );

Console.WriteLine("Time taken to get a document collection: " + elapsedTime);
Console.ReadKey();

本地计算机上的平均输出:

Average output on local computer:

Time taken to get a document collection: 0 seconds, 752 milliseconds

在我的另一段代码中，我正在执行20个小文档更新，每个小文档更新的JSON大小均为400字节，总共仍然需要12秒.我只是从开发环境中运行，但是我期望有更好的性能.

In another piece of my code I'm doing 20 small document updates that are about 400 bytes each in JSON size and it still takes 12 seconds in total. I'm only running from my development environment but I was expecting better performance.

推荐答案

简而言之，这可以使用DocumentDB在〜9毫秒中端到端完成.我将在下面逐步介绍所需的更改，以及它们为何/如何影响结果.

In short, this can be done end to end in ~9 milliseconds with DocumentDB. I'll walk through the changes required, and why/how they impact results below.

在DocumentDB中，第一个查询总是花费更长的时间，因为它完成了一些设置工作(获取DocumentDB分区的物理地址).接下来的几个请求需要花费更长的时间来预热连接池.后续查询将与您的网络一样快(由于SSD存储，DocumentDB中的读取延迟非常低).

The very first query always takes longer in DocumentDB because it does some setup work (fetching physical addresses of DocumentDB partitions). The next couple requests take a little bit longer to warm the connection pools. The subsequent queries will be as fast as your network (the latency of reads in DocumentDB is very low due to SSD storage).

例如，如果您修改上面的代码以进行测量，例如10个读数，而不仅仅是第一个读数，如下所示:

For example, if you modify your code above to measure, for example 10 readings instead of just the first one like shown below:

using (DocumentClient client = new DocumentClient(new Uri(EndpointUrl), AuthorizationKey))
{
    long totalRequests = 10;

    var database = client.CreateDatabaseQuery().Where(db => db.Id == "FamilyRegistry").AsEnumerable().FirstOrDefault();

    Stopwatch watch = new Stopwatch();
    for (int i = 0; i < totalRequests; i++)
    {
        watch.Start();
        var documentCollection = client.CreateDocumentCollectionQuery("dbs/"+ database.Id)
            .Where(c => c.Id == "FamilyCollection").AsEnumerable().FirstOrDefault();

        Console.WriteLine("Finished read {0} in {1}ms ", i, watch.ElapsedMilliseconds);
        watch.Reset();
    }
}

Console.ReadKey();

我在Redmond的桌面上针对Azure West US数据中心获得以下结果，即大约 50毫秒.这些数字可能会根据网络连接和客户端与Azure DC托管DocumentDB的距离而有所不同:

I get the following results running from my desktop in Redmond against the Azure West US data center, i.e. about 50 milliseconds. These numbers may vary based on the network connectivity and distance of your client from the Azure DC hosting DocumentDB:

Finished read 0 in 217ms
Finished read 1 in 46ms
Finished read 2 in 51ms
Finished read 3 in 47ms
Finished read 4 in 46ms
Finished read 5 in 93ms
Finished read 6 in 48ms
Finished read 7 in 45ms
Finished read 8 in 45ms
Finished read 9 in 51ms

接下来，我从默认的网关切换到Direct/TCP连接，以将延迟从两跳提高到一跳，即，将初始化代码更改为:

Next, I switch to Direct/TCP connectivity from the default of Gateway to improve the latency from two hops to one, i.e., change the initialization code to:

using (DocumentClient client = new DocumentClient(new Uri(EndpointUrl), AuthorizationKey, new ConnectionPolicy { ConnectionMode = ConnectionMode.Direct, ConnectionProtocol = Protocol.Tcp }))

现在，通过ID查找集合的操作将在 23毫秒内完成:

Now the operation to find the collection by ID completes within 23 milliseconds:

Finished read 0 in 197ms
Finished read 1 in 117ms
Finished read 2 in 23ms
Finished read 3 in 23ms
Finished read 4 in 25ms
Finished read 5 in 23ms
Finished read 6 in 31ms
Finished read 7 in 23ms
Finished read 8 in 23ms
Finished read 9 in 23ms

当您从也在同一Azure DC中运行的Azure VM或辅助角色运行相同结果时如何?相同的操作大约需要 9毫秒！

How about when you run the same results from an Azure VM or Worker Role also running in the same Azure DC? The same operation completes with about 9 milliseconds!

Finished read 0 in 140ms
Finished read 1 in 10ms
Finished read 2 in 8ms
Finished read 3 in 9ms
Finished read 4 in 9ms
Finished read 5 in 9ms
Finished read 6 in 9ms
Finished read 7 in 9ms
Finished read 8 in 10ms
Finished read 9 in 8ms
Finished read 9 in 9ms

因此，总结一下:

• 对于性能测量，请允许一些测量示例以说明DocumentDB客户端的启动/初始化.
• 请使用TCP/直接连接以降低延迟.
• 如果可能，请在同一Azure区域中运行.
• 如果遵循这些步骤，则可以获得出色的性能，并且可以获得DocumentDB的最佳性能数据.

这篇关于DocumentDB性能问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！