Недавно я прочитал статью о c#-5 и новых и приятных асинхронных функциях программирования. Я вижу, что он работает в приложении windows. Вопрос пришел ко мне, если эта функция может повысить производительность ASP.Net?
рассмотрим этот два кода psudo:
public T GetData()
{
var d = GetSomeData();
return d;
}
и
public async T GetData2()
{
var d = await GetSomeData();
return d;
}
Имеет ли в приложении ASP.Net разницу в двух кодах?
спасибо
Хорошо для начала ваша вторая часть кода вернет Task<T>, а не T. Окончательный ответ - "это зависит".
Если вашей странице требуется доступ к нескольким источникам данных, это может упростить параллельный доступ к этим источникам, используя результат каждого доступа только там, где это необходимо. Так, например, вы можете захотеть начать долговременную выборку данных в качестве первой части обработки вашей страницы, а затем получить результат в конце. Очевидно, это можно сделать без использования async/await, но это намного проще, когда язык помогает вам.
Кроме того, асинхронность может использоваться для обработки большого количества длительных запросов на небольшое количество потоков, если большинство из этих запросов будут простаивать в течение длительного времени - например, в сценарии с длинным опросом. Я вижу, как асинхронные способности используются в качестве альтернативы SignalR в некоторых сценариях.
Преимущества async на стороне сервера сложнее привязать, чем на стороне клиента, потому что есть разные способы, которыми это помогает - тогда как сторона "избегать работы с потоком пользовательского интерфейса" настолько очевидна, что легко см. преимущество.
Не забывайте, что для серверного кодирования может быть намного больше, чем просто интерфейс. По моему опыту, async, скорее всего, будет полезен при внедрении RPC-сервисов, особенно тех, которые говорят с несколькими другими службами RPC.
Как говорит Паси, это просто синтаксический сахар, но я считаю, что он достаточно сладкий сахар, что он вполне может сделать разницу между правильной асинхронной обработкой, и это просто слишком много усилий и сложности.
Определите "производительность".
В конечном итоге приложение будет выполнять ту же работу, что и в синхронном режиме, а именно, что вызывающий поток в асинхронной версии будет ожидать завершения операции над другим, тогда как в синхронной модели тот же поток выполняет задачу.
В конечном итоге в обоих случаях клиент будет ждать столько же времени, прежде чем увидеть ответ с веб-сервера, и поэтому не заметит никакой разницы в производительности.
Если веб-запрос обрабатывается через асинхронный обработчик, то снова ответ будет возвращен на тот же промежуток времени, однако вы можете уменьшить давление на пул потоков, что делает веб-сервер более отзывчивым в принятии запросов - см. этот другой SO для получения более подробной информации об этом.
Так как код выполняется на сервере, и пользователю все равно придется ждать ответа, возникает вопрос: асинхронный вызов идет быстрее, чем вызов синхронизации.
Ну, это зависит в основном от реализации сервера. Для IIS и нескольких пользователей слишком много потоков будет создано для каждого пользователя (даже без async), и async будет неэффективным. Но в случае небольшого количества пользователей он должен быть быстрее.
Один из способов увидеть - попробовать.
Нет. Это чисто синтаксический сахар и облегчить работу в качестве программиста, позволяя писать простой код и читать код просто при исправлении ошибок.
Это позволяет более простой подход к загрузке данных без блокировки пользовательского интерфейса, поэтому да, но не совсем.
Это только увеличит производительность, если вам нужно сделать несколько вещей, которые могут быть выполнены без необходимости в какой-либо другой информации. В противном случае вы можете просто выполнять их последовательно.
В терминах вашего примера ответ отрицательный. Страница должна ждать каждого из них независимо.