Web API 2 - все запросы REST асинхронны?

Question

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

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

Обновление: (У меня плохая привычка не объяснять полностью - извините) Вот моя забота. Клиентский браузер делает запрос REST на мой сервер http://data.domain/com/employee_database/?query=state:Colorado. Это подходит к соответствующему методу в контроллере. Этот метод запрашивает базу данных и возвращает объект, который затем превращается в структуру JSON и возвращается в вызывающее приложение.

Теперь предположим, что 10 000 клиентов выполняют аналогичный запрос на один и тот же сервер. Итак, у меня сразу 10 000 запросов. Будет ли мой метод контроллера вызываться одновременно в 10 000 отдельных потоков? Или должен ли первый запрос вернуться до вызова второго запроса?

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

Answer 1

Чтобы быть честным, ваш вопрос не очень ясен. Если вы делаете HTTP GET с использованием HttpClient, скажем, метод GetAsync, запрос уволен, и вы можете делать все, что хотите, в своем потоке, пока не получите ответ. Таким образом, этот запрос является асинхронным. Если вы спрашиваете о стороне сервера, которая обрабатывает этот запрос (при условии, что это ASP.NET Web API), то асинхронно или не зависит от того, как вы реализовали свой веб-API. Если ваш метод действия выполняет три вещи, скажем, 1, 2 и 3 один за другим синхронно в режиме блокировки, тот же поток отправляет службе запрос. С другой стороны, скажем, что № 2 выше - это вызов веб-службы, и это HTTP-вызов. Теперь, если вы используете HttpClient и вы выполняете асинхронный вызов, вы можете попасть в ситуацию, когда один запрос обслуживается более чем одним потоком. Чтобы это произошло, вы должны были сделать HTTP-вызов из вашего метода действий асинхронно и использовать ключевое слово async. В этом случае, когда вы вызываете await в метод действия, выполняется действие вашего действия, и поток, обслуживающий ваш запрос, может обслуживать какой-либо другой запрос, и в конечном итоге, когда ответ будет доступен, тот же или какой-либо другой поток будет продолжен, откуда был остановлен ранее. Долгий скучный ответ, возможно, но трудно объяснить просто словами, набрав, я думаю. Надеюсь, вы получите некоторую ясность.

UPDATE: Ваш метод действия будет выполнять параллельно в 10000 нитей (в идеале). Почему я говорю в идеале, потому что пул потоков CLR, имеющий 10 000 потоков, не типичен и, вероятно, непрактичен. Существуют физические ограничения, а также ограничения, налагаемые структурой, но, я думаю, ответ на ваш вопрос заключается в том, что запросы будут обслуживаться параллельно. Правильный термин здесь будет «параллельным», но не «асинхронным».

Answer 2

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

Не стесняйтесь ударить async о своем действии и использовать Task.Run. Это асинхронная синхронизация (известный анти-шаблон). Он должен быть действительно асинхронным вплоть до ядра ОС.

Никакой каркас не может синхронизировать IO автоматически асинхронно, так что это не может произойти под капотом. Async IO основан на обратном вызове, что является серьезным изменением в модели программирования.

Это не ответит на то, что вы должно сделать конечно. Это будет новый вопрос.

Answer 3

По умолчанию для REST не существует async. запрос обрабатывается синхронно. Тем не менее, ваш веб-сервер (IIS) имеет несколько параметров максимальных потоков, которые могут работать в одно и то же время, и он поддерживает очередь полученного запроса. Таким образом, запрос отправляется в очередь, и если поток доступен, он запускается иначе, запрос ожидает в очереди IIS до тех пор, пока не будет доступен поток

Answer 4

Я думаю, что вы должны использовать async IO/операции, такие как вызовы базы данных в ваш случай. Да в Web Api, каждый запрос имеет свой собственный поток, но потоки могут закончиться, если есть много последовательных запросов. Также потоки используют память, поэтому, если ваш api попадает в слишком много запросов, он может оказывать давление на вашу систему.

Преимущество использования асинхронной синхронизации заключается в том, что вы разумно используете свои системные ресурсы. Вместо блокировки потока, когда он ожидает завершения вызова базы данных в реализации синхронизации, async освободит поток, чтобы обрабатывать больше запросов или назначать ему то, что требуется процессу для потока. Как только вызов IO (базы данных) завершится, другой поток возьмет его оттуда и продолжит реализацию. Async также сделает ваш api быстрее, если ваши операции ввода-вывода будут занимать больше времени.