Azure DocumentDB 性能低下
Slow performance on Azure DocumentDB
我目前面临 Azure DocumentDB 的响应时间非常慢(第一次尝试)。
一个集合中有 31 个对象,我将把它们取回并 return 给调用者。我使用的代码是这样的:
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
获得的对 return 31 个对象的响应时间在 360 毫秒到 1200 毫秒之间。对我来说,那是 相当 慢。没有自定义 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
已更新以反映最新的服务更改 (1/22/2017): DocumentDB 保证 p99 读取延迟 < 10 毫秒和 p99 写入延迟 < 15 毫秒,数据库端有 SLA .以下提示仍然适用于使用 SDK 实现低延迟读取**
已更新以反映最新的服务更改 (6/14/2016): 通过 user-defined id 使用路由时无需缓存 self-links .还添加了更多提示。**
DocumentDB 存储分区本身的读取通常需要 <1 毫秒;而瓶颈往往是应用程序和数据库之间的网络延迟。因此,最好将应用程序 运行 与数据库放在同一个数据中心。
以下是有关 SDK 使用的一些一般提示:
提示 #1:在应用程序的生命周期内使用单例 DocumentDB 客户端
请注意,每个 DocumentClient 实例都是 thread-safe,并在直接模式下运行时执行高效的连接管理和地址缓存。为了通过 DocumentClient 实现有效的连接管理和更好的性能,建议在应用程序的生命周期内为每个 AppDomain 使用一个 DocumentClient 实例。
技巧 #2:缓存文档和 collection SelfLinks 以降低读取延迟
在 Azure DocumentDB 中,每个文档都有一个 system-generated selfLink。这些 selfLinks 保证在文档的生命周期内是唯一且不可变的。使用 selfLink 读取单个文档是获取单个文档的最有效方法。由于 selfLink 的不变性,您应该尽可能缓存 selfLinks 以获得最佳读取性能。
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:调整 queries/read 提要的页面大小以获得更好的性能
使用读取提要功能(即 ReadDocumentFeedAsync)执行批量文档读取或发出 DocumentDB SQL 查询时,如果结果集太大,将以分段方式返回结果。默认情况下,结果以 100 个项目或 1 MB 的块形式返回,以先达到限制为准。
为了减少检索所有适用结果所需的网络往返次数,您可以使用 x-ms-max-item-count 请求 header 将页面大小增加到最多 1000。如果您需要仅显示少量结果,例如,如果您的用户界面或应用程序 API returns 一次仅显示十个结果,您还可以将页面大小减小到 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 });
更多提示 (6/14/2016):
- 使用 point-reads(例如读取文档而不是查询文档)按 id
查找
- 配置 DocumentDB 客户端(使用 ConnectionPolicy)以使用通过网关的直接连接
- 在与数据库相同的 Azure 区域中并置客户端
- 调用 OpenAsync() 以防止更高的首次调用延迟
- 您可以通过在可查询对象上调用 ToString() 来调试 LINQ 查询,以查看通过网络发送的 SQL 查询
有关更多性能提示,请查看此 blog post。
我目前面临 Azure DocumentDB 的响应时间非常慢(第一次尝试)。
一个集合中有 31 个对象,我将把它们取回并 return 给调用者。我使用的代码是这样的:
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
获得的对 return 31 个对象的响应时间在 360 毫秒到 1200 毫秒之间。对我来说,那是 相当 慢。没有自定义 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
已更新以反映最新的服务更改 (1/22/2017): DocumentDB 保证 p99 读取延迟 < 10 毫秒和 p99 写入延迟 < 15 毫秒,数据库端有 SLA .以下提示仍然适用于使用 SDK 实现低延迟读取**
已更新以反映最新的服务更改 (6/14/2016): 通过 user-defined id 使用路由时无需缓存 self-links .还添加了更多提示。**
DocumentDB 存储分区本身的读取通常需要 <1 毫秒;而瓶颈往往是应用程序和数据库之间的网络延迟。因此,最好将应用程序 运行 与数据库放在同一个数据中心。
以下是有关 SDK 使用的一些一般提示:
提示 #1:在应用程序的生命周期内使用单例 DocumentDB 客户端
请注意,每个 DocumentClient 实例都是 thread-safe,并在直接模式下运行时执行高效的连接管理和地址缓存。为了通过 DocumentClient 实现有效的连接管理和更好的性能,建议在应用程序的生命周期内为每个 AppDomain 使用一个 DocumentClient 实例。
技巧 #2:缓存文档和 collection SelfLinks 以降低读取延迟
在 Azure DocumentDB 中,每个文档都有一个 system-generated selfLink。这些 selfLinks 保证在文档的生命周期内是唯一且不可变的。使用 selfLink 读取单个文档是获取单个文档的最有效方法。由于 selfLink 的不变性,您应该尽可能缓存 selfLinks 以获得最佳读取性能。
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:调整 queries/read 提要的页面大小以获得更好的性能
使用读取提要功能(即 ReadDocumentFeedAsync)执行批量文档读取或发出 DocumentDB SQL 查询时,如果结果集太大,将以分段方式返回结果。默认情况下,结果以 100 个项目或 1 MB 的块形式返回,以先达到限制为准。
为了减少检索所有适用结果所需的网络往返次数,您可以使用 x-ms-max-item-count 请求 header 将页面大小增加到最多 1000。如果您需要仅显示少量结果,例如,如果您的用户界面或应用程序 API returns 一次仅显示十个结果,您还可以将页面大小减小到 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 });
更多提示 (6/14/2016):
- 使用 point-reads(例如读取文档而不是查询文档)按 id 查找
- 配置 DocumentDB 客户端(使用 ConnectionPolicy)以使用通过网关的直接连接
- 在与数据库相同的 Azure 区域中并置客户端
- 调用 OpenAsync() 以防止更高的首次调用延迟
- 您可以通过在可查询对象上调用 ToString() 来调试 LINQ 查询,以查看通过网络发送的 SQL 查询
有关更多性能提示,请查看此 blog post。