Azure ограничивает мой WebApi?

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

У меня есть одна запущенная и работающая простая служба на основе WebApi 2, которая публикуется в Azure. Я ожидаю, что большую часть времени он будет тихим, а затем внезапно, когда игра начнется, он получит 200-400 запросов потенциально очень быстро (игра может длиться всего несколько секунд). Игровой сервер и ИИ взаимодействуют с помощью обычных JSON POST.

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

Мне интересно, думает ли Azure, что это потенциальная атака DOS или что-то в этом роде. Возвращение назад может занять больше секунды, как только все замедлится. Несколько интересных моментов:

  • Это никогда не происходит при локальном размещении.
  • Базы вообще нет.
  • Это происходит даже с простым тестовым ИИ, который просто случайным образом перемещает части (поэтому нет вычислительной нагрузки).
  • Это происходит, когда хост игры также развернут в Azure (то есть два сайта Azure взаимодействуют друг с другом).

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


person Pharylon    schedule 16.10.2014    source источник
comment
В каком плане Azure это включено?   -  person usr    schedule 16.10.2014
comment
Я пробовал его и как общий, и как базовый план. При тестировании в качестве Basic я также пытался увеличить номер экземпляра до 2. Похоже, это не помогло.   -  person Pharylon    schedule 16.10.2014
comment
Эта ссылка может быть вам полезна: ma" title="что ограничивает количество одновременных подключений, которые может сделать мое приложение asp net"> stackoverflow.com/questions/7849884/   -  person Shay    schedule 16.10.2014
comment
Шей, ты был прав. Я хотел бы отметить комментарий как правильный ответ.   -  person Pharylon    schedule 21.10.2014
comment
@Pharylon: не могли бы вы удалить ответ из вопроса и вместо этого опубликовать его как ответ? Вы можете принять свой собственный ответ.   -  person Jeroen Vannevel    schedule 08.01.2015


Ответы (2)


Да, вы могли бы быть ограничены, если бы вы были на бесплатном или общем плане. С бесплатным планом вы получаете 60 минут процессорного времени в день, а с общим — 240 минут процессорного времени в день.

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

Существуют ограничения на веб-сокеты, но я не уверен, является ли это общим ограничением TCP-соединения.

Здесь находится ссылка на пределы.

Я думаю, что базовый план должен дать вам предсказуемую производительность, но малый экземпляр в базовом плане — это всего лишь ЦП 1,6 ГГц, что, скорее всего, будет намного меньше ЦП и ядер, чем ваша локальная машина.

Я думаю, что веб-роль облачной службы стандартного размера A2 (2 ядра) может быть более подходящей, чем веб-сайт. В зависимости от вашего кода (если они могут использовать большую часть ЦП и могут распределять задачи между ролями), гораздо более рекомендуется даже несколько экземпляров A0.

Для честной конкуренции у вас может быть и процессорное ограничение, это очень интересно.

Всего наилучшего, и пусть победит лучший код :)

person Vishalgiri    schedule 17.10.2014

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

person Pharylon    schedule 04.03.2015