Question

我正在针对Azure表存储运行一系列结构良好的查询，据我所知，该查询应该返回亚秒级。实际上，如果我手动运行它们（例如，从Visual Studio中的Azure工具），它们确实会立即返回。但是当我在制作中运行它们时，它们有时会花费20-30秒来返回。

这是我用ATS调用ATS的C＃代码：

public async Task<IList<T>> FindAsync(string filter, int maxRecords = int.MaxValue, IList<string> columns = null)
{
    var returnList = new List<T>();
    try
    {
        Interlocked.Increment(ref _outstandingRequests);
        var query = new TableQuery<T>().Where(filter);
        if (columns != null && columns.Any())
        {
            query = query.Select(columns);
        }
        TableQuerySegment<T> querySegment = null;
        var sw = new Stopwatch();
        sw.Start();
        while (returnList.Count < maxRecords && (querySegment == null || querySegment.ContinuationToken != null))
        {
            try
            {
                await 3.RetriesAsync(async x =>
                {
                    querySegment = await
                        Table.ExecuteQuerySegmentedAsync(query,
                            querySegment != null ? querySegment.ContinuationToken : null);
                });
                returnList.AddRange(querySegment);
            }
            catch (Exception ex)
            {
                _logger.Error("Error executing ATS query; table:{0}; filter:{1}; error:{2}",
                    typeof(T).GetFriendlyTypeName(), filter, ex.CompleteMessage());
                throw;
            }
        }
        sw.Stop();
        if (sw.ElapsedMilliseconds > 10000)
        {
            var stat = new RepoOperationStats(filter, sw, returnList.Count, _outstandingRequests);
            _logger.Warn("Long-running {0} query: secs:{1:0.0}, rc:{2}, or:{3}, fi:{4}",
                typeof(T).GetFriendlyTypeName(), stat.Milliseconds / 1000d, stat.ResultCount, stat.OutstandingRequests, stat.Filter);
        }
    }
    finally
    {
        Interlocked.Decrement(ref _outstandingRequests);
    }
    return returnList;
}

以下是存储在表格中的实体的示例：

enter image description here

一切都相当简单。但在我的日志中，我发现这样的重复错误：

长期运行的AtsOrganizationEventSummaryByCookie查询：秒：33.3， RC：0，或：94， fi :( PartitionKey eq＆＃39; 4306.www-detail-mercury-mars-skywatching-tips.html-get＆＃39;）和（（RowKey ge＆＃39; 2015.02.05.00000000-0000-0000-0000-000000000000＆＃39;）和（RowKey le＆＃39; 2015.02.07.00000000-0000-0000-0000-000000000000＆＃39;））

换句话说，它需要33秒才能返回零行。请注意，它只能命中一个分区，它应该能够对该分区中的行索引进行简单的搜索。（实际上，相同的查询会立即在其他上下文中返回。）

我遇到了某种限制机制吗？我应该注意，我是并行调用这些查询，因此在任何给定的时间点，从十几个到多达100个查询的任何地方都可能是未完成的。但似乎（a）我的客户，（b）ATS应该能够处理这种负载水平。

有关如何解决此问题的任何建议吗？

Azure表存储查询的性能降低

0 个答案: