Стресс-тестирование ядра Entity Framework проходит медленно

  • Я создаю приложение .net core 2.1 с ядром EF.

  • Я использую транзакцию с незафиксированным уровнем изоляции чтения.

  • Я создаю асинхронный API и создаю простой асинхронный запрос ef (получаю 5 полей первого пользователя, а не ссылку на другую таблицу). [запрос пользователя][1]

  • Когда я создаю один запрос, запрос занимает мало времени

  • Когда я выполняю стресс-тест с 10 потоками, нарастание: 5, цикл навсегда (с использованием jmeter), время запроса такое же

  • Однако, когда я нагрузочно тестирую API с помощью jmeter (100 потоков, разгон: 20 с, бесконечный цикл), некоторые запросы занимают мало времени, некоторые запросы занимают много времени (возможно, 5 с, 10 с, 25 с...), другой запрос генерировать исключение тайм-аута соединения

  • Что я должен делать?

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

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

  • Следует использовать уровень изоляции транзакций Read Uncommitted

  • Следует использовать одно и то же подключение к базе данных для нескольких операций по одному запросу.

  • Все API и методы должны быть асинхронными, убедитесь, что вы не смешиваете асинхронный с синхронным.

    Спасибо всем !!!


person Dat Phan    schedule 23.09.2018    source источник
comment
Любая обратная связь по ответу? Если все в порядке, это должно быть принято и проголосовано, чтобы это было полезно для сообщества. Спасибо   -  person UBIK LOAD PACK    schedule 01.10.2018


Ответы (1)


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

Как только вы подтвердите, что проблемы реальны, проверьте несколько вещей:

  • Нет проблемы N+1 Select (циклы запросов)
  • Детализация извлекаемых данных, вы извлекаете слишком много данных
  • производительность SQL-запросов, выдаваемых при просмотре БД?
  • Размер бассейна

Посмотрите интересные блоги:

person UBIK LOAD PACK    schedule 23.09.2018
comment
я обновил вопрос с фотографией, пожалуйста, взгляните на фото пользователя #query. Я установил максимальный размер пула в строке подключения 5000 - person Dat Phan; 23.09.2018