ASP.NET MVC Async Controller vs Server Push (COMET/Reverse Ajax)

Question

Я создаю ASP.NET MVC site, в котором клиенты (браузер) могут совершать вызовы API, которые занимают до 30 минут (или более). обрабатывать. Очевидно, я не мог использовать обычные MVC-контроллеры для этого, так как несколько таких запросов блокировали бы все мои рабочие потоки IIS, оставив другие более быстрые вызовы заблокированными.

Я посмотрел на следующие два варианта: Асинхронные контроллеры

1. ASP.NET MVC в
2. PokeIn библиотека, которая позволяет серверу толчок через обратный AJAX (длинный холдинг HTTP запросов для старых браузеров) или WebSockets (из спецификации HTML5 для новых браузеров)

Теперь оба варианта кажутся хорошим возможным вариантом.

Вариант 1 кажется мне самым легким для реализации. С асинхронными контроллерами мои рабочие потоки IIS не будут заблокированы, что позволит мне быстрее выполнять другие быстрые вызовы API. Однако из контроллера Async documentation я понимаю, что он порождает другой поток, отличный от IIS, который будет заблокирован/ждет завершения моего процесса (30 минут). Я читал это: «Если вы блокируете или спали в контроллере, независимо от того, является ли оно асинхронным или нет асинхронным, это очень плохо».

В варианте 2, если мои клиенты используют новые браузеры, которые поддерживают WebSockets, это, пожалуй, будет наиболее эффективным, поскольку мне не нужно иметь блокирующий поток на стороне сервера. Когда клиент вызывает медленный вызов API, я бы поднял событие, по завершении которого (скажем, через 30 минут) я подниму еще одно событие, чтобы обновить все браузеры моего клиента с обновленным контентом. Однако с помощью библиотеки PokeIn, если у части моих клиентов нет поддерживающих WebSocket браузеров (более старых), я не уверен, если они будут запугать один из моих рабочих потоков IIS.

Возможно ли вариант 2 для излишнего требования? В Варианте 1 плохо, если мой контроллер Async будет ждать медленного процесса? Другим недостатком варианта 1 является то, что если пользователь обновляет страницу до завершения запроса, он больше не получит обновление задания после его завершения!

Любые идеи, предложения приветствуются.

Благодаря

Answer 1

PokeIn использует те же бассейны в памяти/нить, чтобы раздвинуть сообщения для WebSocket и АЯКС соединений, поскольку он имеет внутренний сервер WebSocket. Время доставки, разумеется, отличается для ajax и websocket, но независимо от выбранного метода/опции у вас будет такая разница. Кроме того, возможно, вы уже знаете, но Pokein откидывается на комету ajax на случай, если клиент не поддерживает websocket, и вам не придется с этим справляться.

Надеюсь, этот вопрос ответит на вариант 2.