ASP.Net MVC Отложенные запросы, поступившие после закрытия браузера клиента

Question

Я думаю, что я знаю, что здесь происходит, но будет благодарен за подтверждение и/или материал для чтения, который может превратить это «думать» в просто «знать», актуальные вопросы на конец поста в разделе Tl, DR:

Сценарий:

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

На одной из моих веб-страниц есть JQuery datatable, которая запрашивает обновление через ajax каждые полсекунды - моя текущая задача - отображать правильную ошибку, если эти данные запрашивают время. Поэтому, чтобы проверить, я сделал хранимая процедура, которая просит сервер БД ждать 3 секунды, прежде чем отвечать, что больше, чем настроенные настройки таймаута, поэтому это гарантирует исключение тайм-аута для меня.

Я тестирую браузер Chrome, один клиент. Применение отлаживается в VS2013 IIS Express

Проблема: Не ожидал следующие симптомы, чтобы показать, когда мой целеустремленный замедлиться активируется:

1) После запуска страницы с сфальсифицированы DataTable, приложение замедлилось при обработке всех запросов от клиентского браузера - есть еще 3 компонента, которые отправляют запросы обновления ajax, параллельные тому, который я целенаправленно нарушил, и это же замедление также применяется к любым действиям, которые я сделал в веб-приложении, которое будет генерировать запрос (например, переходить на другие страницы). Отладчик браузера показал, что запросы были отправлены вовремя, но соответствующие точки останова на стороне сервера стали получать гораздо позже (задержки от 10 секунд до нескольких минут)

2) Мой сервер продолжал обрабатывать запросы даже после закрытия вкладки с приложением. Я закрыл браузер, я убедился, что процесс chrome.exe завершен, но контрольные точки на разных действиях Controller по-прежнему попадают в течение 20 минут после этого - в основном на действия, которые были «вызваны», автоматически зацикливая запросы ajax с нескольких страниц I пытался посетить во время моих тестов. Кроме того, на основных страницах, на которые я пытался перейти, были удалены точки останова. Во втором тесте я использовал RawCap для контроля интерфейса loopback, чтобы убедиться, что ничего не происходит, когда запросы выполняются в фоновом режиме.

Теория Я хотел бы подтвердить или опровергнуть с альтернативным объяснением:

Так выше сценарий делает петельные запросы на частоте, что сервер не может обработать - клиент DataTable цикла отправлял их каждые .5 секунд , и для создания тайм-аута каждый из них занимает не менее 3 секунд. И, очевидно, где-то в IIS выражается, что должно быть предел количества параллельных запросов, которые он может обрабатывать ...

Что для меня было неожиданным, так это то, что я предположил, что если этот предел (который я также предположил чтобы существовать), тогда запросы будут отклонены - вместо этого они выглядят в очереди на совершенно бесполезное количество времени для обработки позже - я имею в виду, по какому сценарию было бы полезно обработать запрошенный веб-запрос через полчаса ?

Так мои вопросы до сих пор являются следующие:

Tl, DR вопросы:

ли IIS Express (который поставляется с Visual Studio 2013) имеют параллельное ограничение соединения?

Если да: { Этот лимит настраивается где-то, и если да, то где?

Каким образом службы IIS обрабатывают ситуации, когда этот предел достигнут, - это то, что обработка также настраивается где-то? (Я не имею в виду, как очереди по сравнению с немедленной ошибкой, как сервер занят) }

Если нет: { Как сценарии ручки сервера, когда запросы приходят быстрее, чем они могут быть обработаны и может что обработка быть настроены в любом месте? }

Здесь - http://www.iis.net/learn/install/installing-iis-7/iis-features-and-vista-editions

Я обнаружил, что IIS7 по крайней мере, позволило неограниченное количество silmulatneous соединений, но как это на самом деле работает, если сервер просто не достаточно быстро, чтобы обрабатывать все запросы? Можно ли настроить лимит в любом месте, а также управлять достигнутым лимитом?

Поблагодарили бы за какие-либо ссылки на онлайн-материал для чтения по вышеуказанному.

Answer 1

Во-первых, вот краткий веб-сервер 101. Веб-серверы производственного класса многопоточные и примерно один поток = один запрос. Обычно вы видите какие-то настройки для вашего веб-сервера, называемые его «максимальными запросами», и это, опять же, примерно соответствует количеству потоков, которые он может вызвать. Каждый поток имеет накладные расходы с точки зрения ЦП и ОЗУ, поэтому существует очень реальный верхний предел того, сколько веб-сервера может появиться с учетом ресурсов, на которых работает он.

Когда веб-сервер достигает этого предела, он не начинает отказывать в запросах, а скорее ставит в очередь запросы на обработку, когда потоки освобождаются. Например, если веб-сервер имеет максимальные запросы 1000 (типичные), и он внезапно получает обстрел 1500 запросов. Первые 1000 будут обработаны немедленно, а остальные 500 будут поставлены в очередь до тех пор, пока некоторые из первоначальных запросов не будут откликаться, освобождая потоки и позволяя обрабатывать некоторые запрошенные очереди.

Связанная область темы здесь - асинхронная, которая в контексте веб-приложения позволяет потокам возвращаться в «пул», когда они находятся в состоянии ожидания. Например, если вы говорили с API, есть период ожидания, обычно из-за задержки в сети, между отправкой запроса и получением ответа от API. Если вы обрабатываете это асинхронно, то в течение этого периода поток может быть возвращен в пул для обработки других запросов (например, 500 запросов в очереди из предыдущего примера). Когда API наконец ответит, поток будет возвращен для завершения обработки запроса. Async позволяет серверу более эффективно обрабатывать ресурсы, используя потоки, которые в противном случае были бы бездействующими для обработки новых запросов.

Тогда есть концепция клиент-сервера. В протоколах, таких как HTTP, клиент делает запрос, и сервер отвечает на этот запрос. Однако между ними нет постоянной связи. (Это несколько неверно, как и для HTTP 1.1. Связи между клиентом и сервером иногда сохраняются, но это только для того, чтобы ускорить будущие запросы/ответы, поскольку время, затрачиваемое на инициирование соединения, не является фактором. реальное постоянное сообщение о статусе клиента/сервера, все еще в этом сценарии). Главное здесь, что если клиент, как и веб-браузер, отправляет запрос на сервер, а затем клиент закрывается (например, закрывает вкладку в браузере), этот факт не передается серверу. Все, что знает сервер, это то, что он получил запрос и должен ответить, и ответьте на него, даже если на другом конце нет ничего, чтобы его получить. Другими словами, только потому, что вкладка браузера закрыта, это не означает, что сервер просто прекратит обработку запроса и продолжит работу.

Тогда есть таймауты. Оба клиента и серверы будут иметь некоторое значение тайм-аута, которым они будут следовать. Распределенный характер Интернета (включаемый такими протоколами, как TCP/IP и HTTP), означает, что узлы в сети считаются переходными. Нет постоянного соединения (кроме той же заметки выше), и могут произойти прерывания сети между клиентом, делающим запрос, и сервером, отвечающим на запрос. Если клиент/сервер не планировал этого, они могли бы просто сидеть там навсегда. Однако эти тайм-ауты могут сильно различаться. Обычно сервер будет отвечать на запрос в течение 30 секунд (хотя он может быть установлен неограниченно). Клиенты, такие как веб-браузеры, как правило, немного более прощающие, с тайм-аутами в течение 2 минут или дольше в некоторых случаях. Когда сервер достигнет своего таймаута, запрос будет прерван. В зависимости от почему произошел тайм-аут, клиент может получить различные ответы об ошибках. Однако, когда клиент истекает, на сервере обычно нет уведомлений. Это означает, что если тайм-аут сервера выше, чем у клиента, сервер будет продолжать пытаться ответить, даже если клиент уже перешел. Закрытие вкладки браузера можно рассматривать как мгновенный тайм-аут клиента, но опять же, сервер не является более мудрым и продолжает пытаться выполнять свою работу.

Итак, все это сводится к тому, что это. Во-первых, при длительном опросе (это то, что вы делаете, повторно отправляя запрос AJAX за определенный промежуток времени), вам нужно построить схему отмены. Например, если последние 5 запросов были исчерпаны, вы должны прекратить опрос, по крайней мере, в течение некоторого периода времени. Еще лучше было бы, чтобы ответ одного запроса AJAX инициировал следующее. Итак, вместо того, чтобы использовать что-то вроде setInterval, вы можете использовать setTimeout и инициировать его обратный вызов AJAX. Таким образом, запросы продолжаются только в том случае, если цепочка не повреждена. Если один запрос AJAX завершился неудачей, опрос немедленно прекратится. Однако в этом случае вам может потребоваться некоторое отключение для повторного инициирования цепочек запросов через определенный промежуток времени. Это предотвращает бесконечную бомбардировку вашего уже неудачного сервера новыми запросами. Кроме того, всегда должен быть некоторый верхний предел времени, в течение которого опрос должен продолжаться. Если пользователь оставляет вкладку открытой в течение нескольких дней, не используя ее, должен ли вы действительно продолжать опрос сервера в течение всего этого времени?

На стороне сервера вы можете использовать асинхронный режим с помощью токенов отмены. Это делает две вещи: 1) он дает вашему серверу немного больше передышки, чтобы обрабатывать больше запросов, и 2) он обеспечивает способ раскрутить запрос, если какая-то часть его должна таймаутировать. Более подробную информацию об этом можно найти по адресу: http://www.asp.net/mvc/overview/performance/using-asynchronous-methods-in-aspnet-mvc-4#CancelToken