1 Вопрос: Запросы EFCore ограничены 1000 при многократных запросах в ASP.NET

вопрос создан в Thu, May 2, 2019 12:00 AM

Я заметил, что мое приложение ASP.NET, которое импортирует файлы CSV и превращает их в объекты БД, значительно замедлило процесс импорта.

Информация о версии: EFCore 2.2.3, .NET Core 2.0

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

Я исследовал различные теории, в конце концов я свел его к этому примеру (на самом деле он работает в своем собственном потоке, но для упрощения примера я переместил его в метод контроллера):

Startup.cs

...
// We use an extended DbContext that defines the various DbSets as usual
services.AddDbContext<DatabaseContext>(options => options.UseSqlServer(dbConnectionString));
...

SomeController.cs

private readonly DatabaseContext _context;

public SomeController(DatabaseContext context) 
{
    _context = context;
}

[Route("/SomeController/TestQueries")]
public async Task<JsonResult> TestQueries()
{
    await TestRepeatedQueries();
    return null;
}

private async Task TestRepeatedQueries()
{
    for (var i = 0; i < 10000; i++)
    {
        Debug.WriteLine($"Fetching for iteration {i}");
        _ = await _context.SomeTable.FirstOrDefaultAsync(); // Nothing fancy
        // It doesn't appear that table complexity is a factor
        // The problem occurs even with a simple table with an ID and a few integers
    }
}

При попадании в метод контроллера, журналы показывают, что он весело запускается, запрашивая БД около 1000 итераций, но затем просто останавливается. Похоже, что некоторые случайные рабочие потоки завершаются, и, может быть, через 5 секунд или около того он проходит еще ~ 10 итераций, и так далее.

Я не уверен, что мне здесь не хватает, похоже, что есть какой-то лимит запросов, который был достигнут, и требуется некоторое время для освобождения ресурсов, прежде чем он сможет возобновить работу?

За разъяснениями обращайтесь, пожалуйста!

Update

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

Это не объясняет, что вызвало проблему и как ее воспроизвести, но мне кажется, что где-то есть кеширование /буферизация запросов, которые могут быть заполнены?

    
1
  1. Можете ли вы описать таблицу Drivers. Какое время выполнения?
    2019-05-02 15: 18: 51Z
  2. Кажется, что сложность таблицы не является фактором, то же самое происходит с моей таблицей настроек, которая состоит из идентификатора и 4 целых чисел без отношений или индексов , Время выполнения этих средних значений составляет ~ 2 мс или около того, даже с таблицей драйверов, которая немного сложнее. Похоже, что SQL Profiler показывает, что с SQL-сервером все в порядке, он быстро обрабатывает запросы по мере их поступления, они просто внезапно начинают поступать медленно
    2019-05-02 15: 32: 26Z
  3. Единственное, что бросилось в глаза, это сообщение mssing await на TestRepeatedQueries(); - но это вряд ли проблема
    2019-05-02 15: 49: 16Z
  4. Хорошее замечание, что await действительно есть, я просто пропустил его при записи вопроса!
    2019-05-02 15: 52: 21Z
  5. Воспроизводится ли это в консольном приложении?
    2019-05-02 18: 35: 36Z
1 ответ                              1                         

Я запутался, это связано с отслеживанием сущностей. См. https://docs.microsoft.com/en-us/. ef /core /запросы /отслеживание . await _context.SomeTable.AsNoTracking().FirstOrDefaultAsync(); должно помочь. Я попал в эту конкретную ситуацию, делая сложный импорт. Структуры сущностей треков слишком сильно растут. Другой подход - ограничить количество операций DBContex экземплярами.

    
0
2019-05-02 15: 59: 45Z
  1. Я думал, что это также может иметь место, но такое же поведение, кажется, происходит даже с AsNoTracking() применяется
    2019-05-02 16: 18: 00Z
  2. Вы видели сгенерированные запросы?
    2019-05-02 16: 54: 49Z
  3. Ничего неожиданного, в основном, SELECT TOP(1) s.[Id], s.[Col1], s.[Col2] FROM [SomeTable] AS [s]. SQL-сервер выполняет запрос в < 3 мс, так что с запросами это не вызывает проблем
    2019-05-02 17: 29: 38Z
источник размещен Вот