Вставка заданий Hangfire влияла на производительность API приложения

Question

Я работаю с ASP. NET Многопользовательским приложением Core 2.2 Web API. Приложение использует Hangfire для запуска фоновых задач. Мы пытаемся улучшить производительность приложения.

Он хранит все задания в отдельной БД (Hangfire DB), но это влияет на производительность API. Я проследил запрос API для проверки времени запроса, вот результат:

Вот код

public async Task<string> AddUser(UserModel user)
{
    CreateUserInBackgorund(user);

    // removed code

    return "some status";
}

[Queue(Constants.Critical)]
public void CreateUserInBackgorund(UserModel user)
{
    BackgroundJob.Enqueue(() => CreateUser(user));
}

public async Task CreateUser(UserModel user)
{
    try
    {
        //Other code
    }
    catch (Exception ex)
    {
        _logger.Error(ex.Message, ex);
    }
}

Похоже, что в журналах трассировки фоновые вызовы влияют на производительность запроса. Есть ли способ сократить это время или использовать другой подход?

Answer 1

Из-за некоторой нехватки информации вот несколько советов о том, что проверять:

1. Могут быть проблемы с SQL ожидания сервера THREADPOOL, а не с кодом C# , https://www.sqlskills.com/help/waits/threadpool/ Кроме того, вы можете получить дополнительную информацию о долго выполняющихся запросах с помощью чека SQL Серверные инструменты https://www.sqlshack.com/how-to-identify-slow-running-queries-in-sql-server/ Пожалуйста, имейте в виду, что каждая транзакция блокирует таблицу, и если есть много транзакций в очереди, они также могут значительно снизить производительность.

2. В [Queue (Constants.Critical)] определенно есть лог c, который должен выполнить основной поток запроса прежде чем начать выполнять метод. Также было бы разумно попробовать что-то вроде Task.Run (() => CreateUserInBackgorund (user)); в AddUser (пользователь UserModel) и проверить, как это повлияет.

3. Странная практика - использовать фоновые задания таким образом. Обычно фоновые задания используются в качестве планировщиков для частей бизнес-логики c, которые не выполняются пользователями, и для тех случаев, когда некоторые логики c должны выполняться за указанное c время или период. Например, рассчитывайте что-нибудь каждый день или каждую неделю, месяц и т. Д. c. Если вы используете фоновые задания только для того, чтобы быстрее передать ответ пользователю, было бы лучше использовать некоторую очередь / служебную шину, например RabbitMQ, для обмена сообщениями, а не добавлять слушателей, которые будут выполнять требуемые задачи. Событие on_message_received на требование. Таким образом, нет необходимости использовать Hangfire для тех вещей, которые он не был разработан, и для такого огромного количества пользовательских запросов. Это позволило бы значительно сократить количество связанных с зависанием запросов к своей базе данных и общее давление на сервер SQL.