Медленный вызов API Служба приложений Azure и база данных Azure Standard 50 (S2) с Entity Framework

Question

Я размещаю приложение на Azure для тестирования. Однако многие API-вызовы становятся очень медленными, хотя производительность, похоже, совсем не увеличивается. Один вызов API, который занимает 170 мс локально с IIS Express и SQL Server Express, занимает 14485 мс на Azure. Тестовые данные точно такие же. Происходит много включений, но необходимы данные, и запрос будет еще медленнее, если их нет.

Почему запрос / вызов API намного медленнее в Azure? Я мог бы понять это, если бы производительность смотрела, но ни один параметр не превысил 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

База данных Azure Standard с 50 DTU (S2).

Запрос локального хоста занимает 170 мс

Запрос на обслуживание приложения занимает 14485 мс

Вызов базы данных localhost:

База данных вызова Azure База данных:

Answer 1

Одной из причин такого замедления может быть ограничение пропускной способности (если извлекается каждый объявленный столбец), поскольку пространственные двоичные данные могут быть довольно большими, и если они выбирают несколько строк, вещи могут накапливаться, если их приложение не размещается вместе с БД. Они могут проверить размер этих данных, выполнив что-то вроде приведенного ниже в верхней части возвращаемых строк:

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

Могут быть конкретные случаи, когда Entity Framework / Entity Framework Core могут по-разному обрабатывать этот тип данных, но приведенный здесь ответ сфокусирован на самом типе данных Geography, потенциальном количестве данных, которые он может включать, и влиянии на производительность, которое это будет иметь по заявке.

Дополнительная информация: STNumPoints (тип данных географии) Относится к: SQL Server (начиная с 2008 года), база данных SQL Azure

Answer 2

Обновление:

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; }
}