Должен ли я использовать асинхронные методы в контроллерах ASP.NET Web API

Question

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

Так ведь

1. Означает ли это, что после действия в контроллере (apicontroller) всегда будет создавать новый экземпляр ресурса?
2. Создает ли он новый независимый поток?
3. Мне не нужно беспокоиться, чтобы объявить мой метод в моем контроллере async, потому что он создаст новый поток для любого HTTP-запроса?
4. Для выполнения действия put мне нужно объявить мой метод как асинхронный, чтобы избежать блокировок при использовании веб-ресурса?

Answer 1

1) Означает ли это, что после действия в контроллере (apicontroller) всегда будет создавать новый экземпляр ресурса?

2) Создает ли он новую независимую нить?

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

3) Мне не нужно беспокоиться, чтобы объявить мой метод в моем контроллере как асинхронный, потому что он создаст новый поток для любого HTTP-запроса?

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

4) Для действия PUT мне нужно объявить мой метод как асинхронный, чтобы избежать блокировок при использовании веб-ресурса?

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

Длинная история

веб-служб на основе ASP.NET Web API, который поддерживает исключительно REST, использовать пул .NET Thread отвечать на запросы. Но только потому, что службы по своей сути многопоточны, не делает их масштабируемыми, когда одновременно выполняются многочисленные запросы. Сама причина, по которой потоки объединяются, а не создаются «на лету», объясняется тем, что они являются чрезвычайно дорогостоящим ресурсом, как с точки зрения памяти, так и использования ЦП. Например, каждый поток потребляет около 1 МБ пространства стека, в дополнение к контексту набора регистров и свойствам потока.

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

Мораль этой истории: не блокирует исполняемый поток из служебной операции.

Это именно то, что происходит, когда вы выполняете задачу, связанную с IO, например, когда вы извлекаете или сохраняете данные из базы данных или вызываете службу нисходящего потока.

Если вызов в базу данных должен был занимать несколько секунд или более, а другой вызов приходит (даже для другого метода), дополнительный поток должен быть приобретен из пула потоков.

Благодаря поддержке asynchronous programming в .NET 4.5 и C# 5, чрезвычайно легко написать асинхронные методы для службы веб-API ASP.NET. Просто установите тип возврата либо в «Задача» (если синхронная версия вернет void), либо в «Задача», заменив T типом возврата синхронного метода. Затем изнутри метода выполните неблокирующую операцию async с привязкой к IO.

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

Читать статью полностью на сайте этой Build Async Services with ASP.NET Web API and Entity Framework 6