Проблема с производительностью веб-приложения Azure с использованием Dapper, Azure SQL и. NET Core 3.1 - PullRequest
Новая
       39

Проблема с производительностью веб-приложения Azure с использованием Dapper, Azure SQL и. NET Core 3.1

0 голосов
/ 12 февраля 2020

Мы создали веб-API с NET Core 3.1, Dapper и Azure SQL, которые размещены в веб-приложении Azure. Используя loader.io , мы запустили несколько тестов производительности, которые разочаровали (~ 10 RPS) для экземпляра S1. Каждый вызов API запускает пару запросов SQL, используя Dapper для извлечения данных из базы данных Azure SQL (100 DTU).

Профилировщик Application Insights сделал трассировки, которые говорят, что много времени, проведенного в базе данных: AI performance tip

Путешествие по горячему пути: Hot path

Сама база данных не отображается подчеркнул (DTU или другие метрики): enter image description here

Веб-приложение имеет некоторые пики на процессоре, потоки выглядят нормально: enter image description here

Код вводится с использованием стандарта. NET Core IServiceCollection DI и Scrutor: 

// Injection of all SqlServer repositories.
services.Scan(scan => scan
  .FromAssemblyOf<SomeRepository>()
  .AddClasses(classes => classes.Where(type => type.Name.EndsWith("Repository")))
  .AsImplementedInterfaces()
  .WithTransientLifetime());

Dapper используется в репозиториях SQL Server для получения информации: 

public async Task<IReadOnlyCollection<DocumentRevisionOverview>> GetDocumentRevisionsAsync()
{
  Logger.LogInformation("Starting {Method} on {Class}.", nameof(GetDocumentRevisionsAsync), ClassName);

  var sql = "select statement";

  // databaseParameters.ConnectionString (type is string) is injected via the constructor.
  using (var connection = new SqlConnection(databaseParameters.ConnectionString))
  {
    var documentRevisions = await connection.QueryAsync<DocumentRevisionOverview>(sql);

    Logger.LogInformation("Finished {Method} on {Class}.", nameof(GetDocumentRevisionsAsync), ClassName);

    return documentRevisions.ToList();
  }
}

В наших таблицах базы данных нет varchars, поэтому преобразование varchar в nvarchar не применимо.

  • Все ресурсы расположены в одном ресурсе группа и местоположение.
  • Таблицы содержат только пару сотен записей.
  • JSON, которое возвращается из веб-API, составляет 88 КБ.
  • Dapper должен повторно использовать пул соединений ADO. NET, который основан на строке соединения, которая не не меняется.
  • Формат строки подключения: "Server={server};Initial Catalog={database};Persist Security Info=False;User ID={user};Password={password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;"
  • Индивидуальные вызовы (например, из Почтальона) быстрые, ~ 150 мс:

Что можно сделать Нужно ли дополнительно расследовать причину времени ожидания?

Хороший PS: я был удивлен, увидев 5-кратное улучшение при развертывании в Linux веб-приложении (с P1V2, 2-кратным размером S1).

1 Ответ

0 голосов
/ 12 февраля 2020

Не зная вашей ситуации, это трудно понять наверняка, но я убедился, что Azure SQL медленнее, чем SQL Сервер, довольно много из-за того, что местоположение Azure SQL не близко достаточно для исполняющего сервера, даже в том же центре обработки данных.

На моей последней позиции мы перешли на Azure SQL, затем, из-за того, что наше приложение было тяжелым вычислительным приложением, мы вернулись к SQL Сервер расположен на виртуальной машине, и мы использовали SQL Синхронизация данных c для отправки данных на Azure SQL для резервного копирования.

Это не поможет решить вашу проблему, но Azure SQL лучше всего подходит для внутренних заданий из того, что я нашел.

...