У меня и нескольких других разработчиков есть конкурс ИИ. В принципе, у нас есть простая настольная игра, и у нас есть все написанные AI, которые будут размещаться на наших собственных веб-сервисах, чтобы играть друг против друга.
У меня есть один запуск и запуск, это простая служба на основе WebApi 2, которая публикуется в Azure. Я ожидаю, что в большинстве случаев это будет тихо, а затем, когда игра начнется, она получит 200-400 запросов все потенциально очень быстро (игра может длиться всего несколько секунд). Игровой сервер и AI обмениваются данными со стандартными JSON-сообщениями.
Моя проблема в том, что Azure, похоже, меняет запросы. Первые несколько ходов происходят очень быстро, а затем все замедляется.
Мне интересно, как Azure думает, что это потенциальная атака DOS или что-то в этом роде. Это может занять более секунды, чтобы вернуться назад, когда ситуация замедляется. Несколько интересных моментов:
Итак, как я могу это исправить? Есть ли где-то где-то где-то отсутствует, где я могу сказать Azure, такое поведение ожидается? В настоящее время я использую его как услугу Shared, но раньше я тестировал его как базовый сервис с двумя экземплярами, и я все еще наблюдал замедление.
Проблема заключалась в разрешении одновременных подключений. Клиент был очень неряшлив и создавал новое соединение для каждого запроса. Это привело к тому, что количество подключений превысило лимит. Это можно было бы решить, как в этом ответе (как отметил Шей в комментариях, мне хотелось бы отметить комментарий как правильный ответ!). Но поскольку у меня также есть доступ к клиентскому коду, я исправил его там.
Да, вы могли бы получить дросселирование, если бы вы были на свободном или общем плане. С бесплатным планом вы получаете 60 минут процессорного времени в день, а с Shared вы получаете 240 минут процессорного времени в день.
Также максимальная средняя загрузка памяти (в час) для общего веб-сайта составляет 1 ГБ. Но я предполагаю, что вы уже профилировали свой код для утечек памяти.
Ограничения на websockets ограничены, но я не уверен, что это общий предел TCP-соединения.
Здесь - ссылка для ограничений.
Я думаю, что базовый план должен дать вам предсказуемую производительность, но маленький пример в базовом плане - это процессор с тактовой частотой 1,6 ГГц, который, скорее всего, будет намного меньше процессорных ядер и ядер, чем ваша локальная машина.
Я думаю, что стандартная веб-роль облачной службы размера A2 (2 ядра) может быть более подходящей, чем веб-сайт. В зависимости от вашего кода (если они могут использовать большую часть процессора и могут распределять задачи между ролями) даже несколько экземпляров A0, было бы гораздо более рекомендовано.
Для честной конкуренции у вас может быть и предел ЦП, это очень интересно.
Все самое лучшее, и пусть победит лучший код:)