Разница в производительности между синхронным обработчиком HTTP и асинхронным обработчиком HTTP

ASP.NET использует пул потоков для обработки входящих HTTP-запросов.

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

Напротив, при использовании IHttpAsyncHandler существует механизм, позволяющий запросу зарегистрировать обратный вызов и вернуть поток пула потоков в пул до того, как запрос будет полностью обработан. Поток пула потоков начинает некоторую обработку запроса. Вероятно, вызывает какой-то асинхронный метод для вызова базы данных или веб-службы или чего-то еще, а затем регистрирует обратный вызов для вызова ASP.NET, когда этот вызов возвращается. В этот момент поток пула потоков, который обрабатывал HTTP-запрос, возвращается в пул для обработки другого HTTP-запроса. Когда вызов базы данных или что-то еще возвращается, ASP.NET запускает зарегистрированный обратный вызов в новом потоке пула потоков. Конечным результатом является то, что у вас нет потоков пула потоков, ожидающих операций ввода-вывода, и вы можете использовать свой пул потоков более эффективно.

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

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

Синхронный код проще. Вы отправляете запрос, и поток останавливается, пока не будет получен ответ. Затем вы можете обрабатывать ответ и ошибки одним и тем же методом. Легко читать и отлаживать. Если вы запустите этот код в потоке графического интерфейса пользователя, Windows может сообщить, что ваша программа «не отвечает», если вы не получите ответ быстро.

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

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