Асинхронизирует и ожидает повышения производительности приложения ASP.Net - PullRequest
Новая
       35

Асинхронизирует и ожидает повышения производительности приложения ASP.Net

14 голосов
/ 26 марта 2012

Я недавно прочитал статью о c#-5 и новых замечательных функциях асинхронного программирования. Я вижу, это работает лучше в приложении Windows. У меня возник вопрос: может ли эта функция повысить производительность ASP.Net?

рассмотрим два псевдокода: 

public T GetData()
{
    var d = GetSomeData();
    return d;
}

и 

public async T GetData2()
{
    var d = await GetSomeData();   
    return d;
}

Имеет ли в приложении ASP.Net разницу между двумя кодами?

спасибо

Ответы [ 5 ]

15 голосов
/ 26 марта 2012

Хорошо, для начала ваш второй фрагмент кода вернул бы Task<T>, а не T.Окончательный ответ - «это зависит».

Если вашей странице требуется доступ к нескольким источникам данных, она может упростить распараллеливание доступа к этим источникам, используя только результаты каждого доступа.где необходимо.Так, например, вы можете запустить , делая длительную выборку данных в качестве первой части обработки вашей страницы, тогда вам нужен только результат в конце.Очевидно, что это можно сделать без использования async / await, но намного проще, когда язык помогает вам.

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

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

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

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

6 голосов
/ 26 марта 2012

Определить «производительность».

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

В конечном итоге в обоих случаях клиент будет ждать одинаковое количество времени, прежде чем увидит ответ от веб-сервера, и, следовательно, не заметитлюбая разница в производительности.

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

1 голос
/ 26 марта 2012

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

С точки зрения вашего примера, ответ - нет.Страница должна ждать каждого независимо.

1 голос
/ 26 марта 2012

Нет.Это чисто синтаксический сахар и облегчает вашу работу программиста, позволяя писать простой код и читать код просто, когда вы исправляете ошибки.

Это позволяет упростить загрузку данных без блокировки пользовательского интерфейса, таким образом,да, но не совсем

1 голос
/ 26 марта 2012

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

Ну, это зависит в основном от реализации сервера.Для IIS и нескольких пользователей слишком много потоков будет порождено на пользователя (даже без асинхронности), и асинхронность будет неэффективной.Но в случае небольшого количества пользователей это должно быть быстрее.

Один из способов увидеть это попробовать.

...