Задержка между веб-ролью Azure и SQL Azure и производительностью приложений

Question

Azure Web Role и Sql Azure Latency

Привет! Просто чтобы знать, что между ролью веб-работника и SQL Azure существует задержка и время ожидания, иногда происходит событие a Timeout (это часто не случайно) 40% из 100 пингов не имеют времени ожидания 0 мс

если роль веб-работника и SQL Azure в одном центре обработки данных, ПОЧЕМУ истекло время ожидания, так как они обмениваются данными с использованием своей внутренней сети

Просьба ссылаться на прикрепленные скриншоты:

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

Спасибо,

Answer 1

Прежде всего, вам необходимо знать, что база данных SQL Azure Windows - это многопользовательская СУБД высокой плотности, предлагаемая в качестве службы. Это означает, что один сервер используют, возможно, сотни клиентов.

Я также предлагаю вам ознакомиться с SLA для сервисов, в частности, с базой данных Windows Azure SQL. Никто никогда не утверждал, что будет задержка 0 мс. В базе данных SQL WIndows Azure также есть такая вещь, как " переходные условия".

Рекомендуется прочитать руководство по производительности и эластичности базы данных Windows Azure SQL.

Что касается производительности веб-приложений, после прочтения руководства по производительности и эластичности я не думаю, что 200 мс, которые происходят время от времени, являются основным узким местом.

ОБНОВЛЕНИЕ после первого комментария

У вас всегда будут взлеты и падения в общей среде. Также следует ожидать, что время выполнения запроса будет меняться вверх и вниз. Это неизбежно в такой среде, в которой вы должны разрабатывать и жить. Здесь нет волшебной палочки и нет выделенного сервера для вас (для нас) в случае Windows Azure SQL Database. Если вы считаете, что вашему приложению нужны более надежные службы SQL Server, вы можете попробовать виртуальные машины Windows Azure и самостоятельно запустить кластер SQL Server. Я предполагаю (и это только предположение), что связь между вашей облачной службой и вашими виртуальными машинами, если все находится в одном наборе доступности, будет более предсказуемой.

Обновление после 2-го и 3-го комментариев:

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

ОБНОВИТЬ

Интересно отметить, что на всех ваших скриншотах задерживается только первый пакет, затем каждый последующий имеет 0 задержек. Во всех образцах вы предоставляете. Если это ваш случай 10 из 10 раз, то у вас точно не будет проблем с задержкой. Я предлагаю вам использовать опцию "-t" в обычном пинге для отправки более 4-х пакетов и наблюдения. Я предлагаю разбить около 100 пакетов, а затем наблюдать за результатами. Я бы не стал принимать во внимание 4 выборки пакетов, где только первая имеет задержку для любого анализа производительности.

Answer 2

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

Я пытался перенести наше бизнес-приложение в облако. Учитывая, что нашим локальным серверам уже более 8 лет, со службами Azure должно произойти заметное улучшение. Однако, когда мы протестировали наше приложение и провели сравнение производительности облака по сравнению с локальными системами, мы заметили, что задержка в облаке почти в 3 раза больше, чем на локальных (серверы старше 8 лет), и в 20 раз больше, если сравнивать их с использованием современного оборудования. Наше приложение представляет собой приложение asp.net, и его размер составляет около 11 ГБ.

SQL Azure и производительность

1. Никогда не используйте пул соединений в облаке. Если вы это сделаете, ваши запросы будут опущены влево, вправо и в центр. Вместо этого откройте одно соединение и держите его открытым, пока не закончите.
2. Используйте кеширование. У вас нет выбора, если у вас есть надежда сделать эту работу. У меня есть один сайт успешно в облаке, но мне пришлось использовать кеширование, чтобы получить какую-то разумную производительность от него.
3. Поймите, что это не ваша вина! Команде Azure нужно исправить свой конец больше, чем вы. У нас есть скудное приложение, мы обновляли, дорабатывали и оптимизировали в течение 10 лет, и если мы не сможем заставить его работать, вы тоже не сможете.

Мне нравится Azure как концепция. Мне нравятся варианты. Мне нравится расширяемость, но мне не нравится производительность. Я надеюсь, что Microsoft уделит этому больше внимания и внесет некоторые изменения, потому что никто не должен перенести свой бизнес туда, пока это не будет исправлено.

тесты

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

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

Тест 1 - Веб и БД на одной и той же хорошей машине

• Четырехъядерный процессор 2,5 ГГц, 8 ГБ оперативной памяти при 800 МГц с 1300 FSB и SQL 2005
• дает 290 мс времени отклика.

Тест 2 - Веб и БД на одной машине

• SQL и Web на 2 Proc (двухъядерный 3,0 ГГц), 16 ГБ Ram @ 200 МГц с 200 FSB и SQL 2005 Действительно старый IBM Server.
• Веб и SQL оба локальны друг для друга
• дает время отклика 656 мс.

Тест 3 - Веб отдельно от БД

• SQL на 2 Proc (двухъядерный 3,0 ГГц), 16 ГБ оперативной памяти @ 200 МГц с 200 FSB и SQL 2005
• Web на 1 Proc, двухъядерный 3,0 ГГц, 8 ГБ оперативной памяти @ 200 МГц с 200 ФСБ
• Действительно старый IBM Server.
• Веб на одной машине и SQL на другой.
• дает 796 мс времени отклика.

Тест 4 - Лазурь

• Средний ВМ на Лазурном
• SQL Azure DB
• дает 3174 мс времени отклика.

Выводы

• Для меня разница в задержке при переходе от сценария с одним сервером к сценарию с двумя серверами составила 140 мс.
• Переход от этого сценария к Azure занял 2,518 мс. это в 17,98 раза хуже, чем на моих 8-летних машинах.

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