2

我在 Azure 上托管了一个应用程序用于测试目的。然而，尽管性能似乎根本没有达到极限，但许多 API 调用变得非常缓慢。使用 IIS Express 和 SQL Server Express 的一次 API 调用在本地需要 170 毫秒，而在 Azure 上需要 14485 毫秒。测试数据完全相同。有很多包含正在进行，但需要数据，如果包含不存在，查询会更慢。

为什么 Azure 上的查询/API 调用如此之慢？如果性能在窥探，但没有一个参数达到 60% 以上，我可以理解。

代码：

var results = db.ElectoralDistrictResults
    .AsNoTracking()
    .Where(x => x.ElectoralDistrict.Code == addressViewModel.ElectoralDistrictCode)
    .Include(x => x.MunicipalityElectoralDistrictResult.MunicipalityResult.ConstituencyResult.CountyResult.Election.Votes.Select(y => y.Party))
    .Include(x => x.MunicipalityElectoralDistrictResult.MunicipalityResult.ConstituencyResult.CountyResult.Election.ElectionTurnout)
    .Include(x => x.MunicipalityElectoralDistrictResult.MunicipalityResult.ConstituencyResult.CountyResult.Votes.Select(y => y.Party))
    .Include(x => x.MunicipalityElectoralDistrictResult.MunicipalityResult.ConstituencyResult.CountyResult.ElectionTurnout)
    .Include(x => x.MunicipalityElectoralDistrictResult.MunicipalityResult.ConstituencyResult.CountyResult.County)
    .Include(x => x.MunicipalityElectoralDistrictResult.MunicipalityResult.ConstituencyResult.Votes.Select(y => y.Party))
    .Include(x => x.MunicipalityElectoralDistrictResult.MunicipalityResult.ConstituencyResult.ElectionTurnout)
    .Include(x => x.MunicipalityElectoralDistrictResult.MunicipalityResult.Votes.Select(y => y.Party))
    .Include(x => x.MunicipalityElectoralDistrictResult.MunicipalityResult.ElectionTurnout)
    .Include(x => x.MunicipalityElectoralDistrictResult.Votes.Select(y => y.Party))
    .Include(x => x.MunicipalityElectoralDistrictResult.ElectionTurnout)
    .Include(x => x.ElectionTurnout)
    .Include(x => x.Votes.Select(y => y.Party))
    .Include(x => x.MunicipalityElectoralDistrictResult.MunicipalityResult.Municipality.County)
    .Include(x => x.MunicipalityElectoralDistrictResult.MunicipalityElectoralDistrict)
    .Include(x => x.ElectoralDistrict)
    .ToList();

表现：

应用服务：

Basic: 1 Medium
B2
2x cores
200 total ACU
3.5 GB memory
A-Series compute

在此处输入图像描述

具有 50 个 DTU (S2) 的 Azure 标准数据库。

在此处输入图像描述

本地主机请求需要 170 毫秒

在此处输入图像描述

应用服务请求需要 14485 毫秒

在此处输入图像描述

数据库调用本地主机：

在此处输入图像描述

数据库调用 Azure 数据库：

在此处输入图像描述

4

2 回答 2

1

更新：

TL;DR：对慢速查询使用索引可以解决问题。

http://capesean.co.za/fixing-slow-performance-with-azure-sql-database/

如何使用 EF 6.1 创建空间索引：

https://stackoverflow.com/a/36460716/3850405

原来的：

在花费了大量时间之后，它似乎与DbGeography课程有关。geography在 Azure Sql Server 和 SQL Server Express 中与数据类型一起保存。排除此属性时，查询的执行速度只比本地慢一点。我不认为数据类型是正常的。将询问 Azure 是否在处理此数据类型时遇到问题。

在此处输入图像描述

public class Municipality
{
    [Key]
    [DatabaseGenerated(DatabaseGeneratedOption.None)]
    public string Code { get; set; }

    public string Name { get; set; }

    public DbGeography Area { get; set; }

    [ForeignKey("County")]
    public string CountyCode { get; set; }

    public virtual County County { get; set; }
}

在此处输入图像描述

于 2018-09-25T19:12:33.520 回答
0

速度变慢的原因之一可能是由于带宽限制（如果正在获取每个声明的列），因为空间数据 blob 可能非常大，并且如果它们正在获取多行，如果他们的应用程序没有并置，事情就会堆积起来与数据库。他们可以通过在返回的行之上执行以下操作来检查此数据的大小：

SUM((2 + points.HasZ + points.HasM)*8*points.STNumPoints()) as [Approx Bytes]

可能存在 Entity Framework/Entity Framework Core 可能以不同方式处理此数据类型的特定实例，但此处提供的答案侧重于 Geography 数据类型本身，以及它可能包含的潜在数据量以及这将对应用程序产生的性能影响.

附加信息：STNumPoints（地理数据类型） 适用于：SQL Server（从 2008 年开始）、Azure SQL 数据库

于 2018-09-27T15:25:20.783 回答