EF Core AddAsync и SaveChangesAsync немного медленнее после простоя приложения в течение длительного времени

Question

В настоящее время я выполняю тестирование для своих API и заметил небольшую задержку при первой операции сохранения с использованием EF Core.Ситуация заключается в том, что после некоторого периода бездействия (скажем, 18 часов) первая операция сохранения может занять 1,5 секунды, а впоследствии - максимум 100 мс.Ниже приведен фрагмент кода,

         public async Task SaveLog(Log log_item)
         {
              // Set created and updated date/time
              log_item.created = DateTime.UtcNow;
              log_item.updated = DateTime.UtcNow;

              if (!(log_item.Month % 2 == 0))
              // Odd
              {
                  var log_item_odd = log_item.ConvertLogToOdd();
                  await _dbContext.Log_Odd.AddAsync(log_item_odd);
              }
              else
              // Even
              {
                  var log_item_even = log_item.ConvertLogToEven();
                  await _dbContext.Log_Even.AddAsync(log_item_even);
              }

              await _dbContext.SaveChangesAsync();
         }

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

[2018-12-29 06:25:00.199] [ADD_LOG] SaveLog 1556  
[2018-12-29 06:25:01.056] [UPDATE_LOG] UpdateLog 362  
[2018-12-29 06:27:13.652] [ADD_LOG] SaveLog 4  
[2018-12-29 06:27:13.886] [UPDATE_LOG] UpdateLog 9  
[2018-12-29 06:29:01.633] [ADD_LOG] SaveLog 4  
[2018-12-29 06:29:01.846] [UPDATE_LOG] UpdateLog 4  
[2018-12-29 06:56:21.544] [ADD_LOG] SaveLog 53  
[2018-12-29 06:56:21.996] [UPDATE_LOG] UpdateLog 5  
[2018-12-29 07:11:58.813] [ADD_LOG] SaveLog 94  
[2018-12-29 07:11:59.051] [UPDATE_LOG] UpdateLog 5  
[2018-12-29 07:16:12.241] [ADD_LOG] SaveLog 3  
[2018-12-29 07:16:12.639] [UPDATE_LOG] UpdateLog 4 

Я не смог найти ничего, связанного с EF Core, требующего некоторого времени для загрузки после некоторого периода бездействия, есть ли объяснение этому?* Я использую PostgreSQL в качестве базы данных.

Любая помощь приветствуется, спасибо.

Answer 1

Обычно все провайдеры имеют некоторые реализации для сокращения незанятых соединений после периода простоя.

Первая команда занимает немного больше времени, чтобы создать и открыть соединение.Следующие команды будут использовать пул соединений, и они будут быстрее.Затем после простоя в течение определенного времени провайдеры сокращают пул и закрывают незанятые соединения.Затем следующая команда после простоя должна открыть соединение, что снова требует времени.

Например, для Npgsql есть PruneIdleConnectors в ConnectorPool, который выполняет очистку на основе значения NpgsqlConnectionStringBuilder.ConnectionIdleLifetime, что по умолчанию составляет 5 минут.Ниже приведены параметры pooling :

• Время простоя соединения : Время ожидания в секундах до закрытия незанятых соединений в пуле, есликоличество всех соединений превышает MinPoolSize.Начиная с версии 3.1. 300 секунд по умолчанию.
• Интервал отсечения соединений : Сколько секунд пул ожидает, прежде чем попытаться удалить незанятые соединения, срок жизни которых истек (см.ConnectionIdleLifetime).Начиная с версии 3.1. 10 секунд по умолчанию.

Для ADO.NET SqlConnection пул это время составляет приблизительно 4-8 минут:

Диспетчер подключений удаляет подключение из пула после того, как он простаивал в течение приблизительно 4-8 минут, или если диспетчер обнаружил, что соединение с сервером было разорвано.

Примечание: Это уже упоминалось и в комментариях, есть некоторые другие факторы, которые могут повлиять на первое время выполнения, в том числе пул контекста EF и кэш плана выполнения запроса в СУБД.Но обычно самым трудоемким из них является повторное открытие соединения.