Жизненный цикл WebAPI/очередь запросов

У меня есть приложение AngularJS, которое вызывает WebAPI. Если я регистрирую время, когда я инициирую запрос (в моем контроллере angular), и регистрирую время выполнения OnActionExecuting (в фильтре действий в моем контроллере WebAPI), я иногда замечаю разрыв ~ 2 секунды. Я предполагаю, что перед этим фильтром больше ничего не работает, и это связано с тем, что запросы заблокированы/поставлены в очередь. Причина, по которой я это предполагаю, заключается в том, что если я удалю все другие вызовы данных, я не увижу этот пробел.

Какое количество параллельных запросов WebAPI может обрабатывать одновременно? Я попытался просмотреть мониторы производительности ASP.NET, но не смог найти, где можно увидеть эти данные. Может ли кто-нибудь пролить свет на это?


asp.net asp.net-web-api performance-monitor
person user472292    schedule 20.12.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

На этот вопрос нет прямого ответа, но самый короткий...

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

... Но раз уж вы спросили, давайте рассмотрим некоторые основные вещи, которые мы можем предположить о нашем сервере и нашем приложении...

  1. одновременные соединения

Типичный сервер известен такими проблемами, как "c10k"... https://en.wikipedia.org/wiki/C10k_problem ... так что это накладывает жесткое ограничение на количество одновременных подключений.

Предполагая, что каждый вызов WebApi выполняется, скажем, из некоторого вызова AJAX на веб-странице, это дает нам ограничение в 10 000 подключений, прежде чем что-то пойдет не так.

2. Накладные расходы, связанные с зависимостями

Если мы затем рассмотрим сложность рассматриваемого кода, у вас может возникнуть узкое место при выполнении таких вещей, как SQL-запросы, я часто писал контроллеры WebApi, которые имеют бизнес-логику, которая выполняет 10+ запросов к БД, накладные расходы здесь могут быть вашей проблемой?

  1. Подача в накладных расходах

А как насчет пропускной способности сети до сервера? Давайте предположим, что мы передаем 1 МБ данных для каждого вызова, не потребуется много времени, чтобы забить линию Ethernet со скоростью 1 Гбит / с сообщениями такого размера.

  1. Накладные расходы на обработку

Предполагая, что вы написали API, который выполняет сложные вычисления (например, создание сетки для сложных 3D-данных), вы можете легко задушить свой процессор на некоторое время при каждом запросе.

  1. Тайм-ауты

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

...

Итак, как видите, это ни в коем случае не исчерпывающий список, но он описывает сложность заданного вами вопроса. Тем не менее, я бы сказал, что WebApi (фреймворк) не имеет ограничений, это действительно связано с инфраструктурой вокруг него, которая имеет ограничения, чтобы определить, что может быть возможно.

person War    schedule 07.01.2016