В чем преимущество использования async с MVC5?


в чем разница между:

public ActionResult Login(LoginViewModel model, string returnUrl)
{
    if (ModelState.IsValid)
    {
        IdentityResult result = IdentityManager.Authentication.CheckPasswordAndSignIn(AuthenticationManager, model.UserName, model.Password, model.RememberMe);
        if (result.Success)
        {
            return Redirect("~/home");
        }
        else
        {
            AddErrors(result);
        }
    }
    return View(model);
}

и:

[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Login(LoginViewModel model, string returnUrl)
{
    if (ModelState.IsValid)
    {
        IdentityResult result = await IdentityManager.Authentication.CheckPasswordAndSignInAsync(AuthenticationManager, model.UserName, model.Password, model.RememberMe);
        if (result.Success)
        {
            return Redirect("~/home");
        }
        else
        {
            AddErrors(result);
        }
    }
    return View(model);
}

Я вижу, что код MVC теперь имеет асинхронность, но в чем разница. Дает ли один гораздо лучшую производительность, чем другой? Легче ли отлаживать проблемы с одним, чем с другим? Должен ли я вносить изменения в другие контроллеры для моего приложения, чтобы добавить асинхронность ?

3 112

3 ответа:

асинхронные действия полезны только при выполнении связанных операций ввода-вывода, таких как вызовы удаленного сервера. Преимущество асинхронного вызова заключается в том, что во время операции ввода-вывода нет ASP.NET используется рабочий поток. Итак, вот как работает первый пример:

  1. когда запрос попадает в действие, ASP.NET берет поток из пула потоков и начинает его выполнение.
  2. The IdentityManager.Authentication.CheckPasswordAndSignIn метод вызывается. Это блокирующий вызов - > во время всего вызова работника нить находится под угрозой.

и вот как работает второй вызов:

  1. когда запрос попадает в действие, ASP.NET берет поток из пула потоков и начинает его выполнение.
  2. The IdentityManager.Authentication.CheckPasswordAndSignInAsync вызывается, который немедленно возвращается. Зарегистрирован порт завершения ввода / вывода и ASP.NET рабочий поток освобождается в пул потоков.
  3. позже, когда операция завершается, порт завершения ввода-вывода сигнал, другой поток обращается из пула потоков, чтобы закончить возвращение зрения.

Как вы можете видеть во втором случае ASP.NET рабочие потоки используются только в течение короткого периода времени. Это означает, что в пуле доступно больше потоков для обслуживания других запросов.

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

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

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

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