Количество экземпляров, необходимых для приложения Windows Azure

Самый очевидный ответ: лучше всего протестировать это самостоятельно и посмотреть, как работает ваше приложение. Вы можете легко получить счетчики производительности и другие диагностические данные из Windows Azure; например, вы можете подключить Microsoft SCOM (System Center Operations Manager) для мониторинга вашей среды во время тестирования. Site Hammer – это простой инструмент нагрузочного тестирования для Windows Azure (в галерее кода MSDN).

Помимо этого очень очевидного ответа, я поделюсь некоторыми предположениями: учитывая тип нагрузки, вам, вероятно, лучше иметь больше маленьких экземпляров, а не меньшее количество больших, тем более, что ваше хранилище уже разделено. Если вы действительно собираетесь иметь 30 тысяч посетителей одновременно и дать им примерно 15-секундный интервал между чтением вопросов и публикацией их ответов, вы просматриваете 2000 запросов в секунду. 10 узлов должно быть более чем достаточно, чтобы справиться с такой нагрузкой. Помните, что это всего лишь простая оценка, в которой отсутствует какое-либо представление о вашей архитектуре и т. д. Для этих типов нагрузок кэширование — очень хорошая идея; это резко увеличит нагрузку, которую может выдержать каждый узел.

Тем не менее, лучший совет, который я могу вам дать, — убедиться, что вы активно наблюдаете. Для запуска дополнительных экземпляров требуется менее 30 минут, поэтому, если вы следите за своей средой и/или следите за тем, чтобы получать уведомления всякий раз, когда она начинает задыхаться, вы можете легко обновить свою установку. Имейте в виду, что вам необходимо связаться со службой поддержки клиентов, чтобы иметь возможность пройти более 20 экземпляров (это ограничение по умолчанию, установленное для защиты вас от перерасхода средств).

Помимо мудрого совета, который дал вам tijmenvdk, ​​позвольте мне добавить свое мнение о размере инстанса. Как правило, выбирайте наименьший размер, который будет поддерживать ваше приложение, а затем масштабируйте его, чтобы справиться с возросшим трафиком. Таким образом, при уменьшении масштаба минимальная стоимость вычислений остается низкой. Если вы запустили, скажем, пару очень больших инстансов в качестве базового плана (поскольку вам всегда нужно как минимум два инстанса, чтобы получить SLA безотказной работы), ваши затраты начинаются с 0,12 x 8 x 2 = 1,92 доллара США в час, даже в период низкой производительности. время трафика. Если вы используете небольшие экземпляры, вы получите 0,12 x 1 x 2 = 0,24 доллара США в час.

Размер каждой виртуальной машины связан с ЦП, памятью и локальным (недолговременным) дисковым хранилищем, поэтому выберите единицу наименьшего размера, в которой эффективно работает ваше приложение.

Для нагрузочного тестирования/тестирования производительности вы также можете рассмотреть решение на хостинге, такое как Loadstorm.

Насколько одновременны запросы в действительности? Будут ли они все вводить адрес в одно и то же время?

Тем не менее, профилируйте свое приложение локально, это позволит вам оценить использование ЦП, сети и памяти в Azure. Затем вместо того, чтобы смотреть на то, сколько экземпляров вам нужно, посмотрите, как вы можете уменьшить требования! Примените эти советы и снова создайте профиль локально.

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

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

Объедините их, если это возможно, и, чтобы получить действительно масштабируемое, отправьте статические файлы (css, js и изображения) в CDN. Все это уменьшает количество запросов, с которыми приходится иметь дело веб-серверу, и, следовательно, уменьшает количество необходимых веб-ролей = меньше сети.

Как ashx возвращает ответ? то есть отправляет ли он html, xml или json? лично я бы заставил его возвращать JSON, так как для этого потребуется меньшая пропускная способность сети и, скорее всего, меньшая обработка на стороне сервера = меньше памяти и сети.

Используйте асинхронный API для доступа к лазурному хранилищу (при этом используются порты завершения ввода-вывода, чтобы освободить поток iis для обработки дополнительных запросов, пока лазурное хранилище не вернется = включение масштабирования процессора)

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

Все эти советы в равной степени применимы к обычному веб-приложению на одном сервере или в среде веб-фермы.

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