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

Question

Я недавно прочитал статью о 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 разницу между двумя кодами?

Спасибо

Answer 1

Ну, для начала ваш второй кусок кода вернется Task<T> скорее, чем T, Окончательный ответ - "это зависит".

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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