Что лучше с точки зрения производительности, 2 экземпляра средних ролей или 4 небольших экземпляра роли?Azure web and worker role - 2x небольшие экземпляры или 1x среда?
Каковы преимущества и недостатки каждой конфигурации?
Для начала вы не получите гарантированное время безотказной работы 99%, если у вас есть как минимум 2 роли экземпляров роли, это позволяет умереть и быть перезапущенным, в то время как другой берет на себя бремя. В противном случае, это пример того, сколько вы хотите заплатить и какие спецификации вы получаете по каждому. Это не вызвало у меня каких-либо хлопот, имеющих более одного роль ролевой экземпляр, Azure скрывает трудный материал.
Единственный реальный способ узнать, пользуетесь ли вы преимуществами больших экземпляров, пытается и измерить, а не спрашивать здесь. This article имеет таблицу, в которой говорится, что средний экземпляр имеет все, что в два раза больше, чем маленькое. Однако в реальной жизни ваш пробег может различаться и как это влияет на ваше приложение, только вы можете измерить.
Меньшие роли имеют одно важное преимущество - если экземпляры не работают в отдельности, вы получаете меньшую деградацию производительности. Предположим, что вы знаете о требовании «гарантированного времени безотказной работы», имея как минимум два экземпляра, вам нужно выбирать между двумя средними и четырьмя небольшими экземплярами. Если один небольшой экземпляр не работает, вы теряете 1/4 от своей производительности, но если один экземпляр среднего экземпляра не работает, вы теряете половину производительности.
Экземпляры не удастся, если, например, у вас есть необработанное исключение внутри Run() вашего потомка точки входа в роль, а иногда что-то не так-то пошло не так, и ваш код не может справиться с этим, и лучше просто перезапустить. Не то чтобы вы были намеренно нацелены на такие неудачи, но вы должны их ожидать и принять меры для минимизации воздействия на ваше приложение.
Таким образом, нижняя строка - невозможно сказать, какая из них имеет лучшую производительность, но последствия безотказной работы столь же важны, и они явно в пользу меньших экземпляров.
Хорошие баллы от @sharptooth. Еще одна вещь, которую следует учитывать: при масштабировании в наименьшее количество экземпляров - один, а не ноль. Итак, скажите, что у вас есть рабочая роль, выполняющая какую-то ночную задачу в течение часа, и для выполнения работы в этот таймфрейм требуется либо 2 средних, либо 4 небольших экземпляра. Когда работа будет выполнена, вам может потребоваться сэкономить затраты, масштабируя ее до одного экземпляра и позволяя ей работать как один экземпляр в течение 23 часов до следующей ночной работы. При использовании одного Small экземпляра вы будете записывать 23 основных часа, а с помощью одного экземпляра Medium вы будете записывать 46 основных часов. Это мышление также относится к вашей веб-роли, но, вероятно, более важно, так как у вас, вероятно, будет минимум два экземпляра, чтобы убедиться, что у вас есть SLA для безотказной работы (для вас может быть не так важно иметь SLA для вашего работника, если, скажем, ваш конец пользователь никогда не взаимодействует с ним, и это просто для служебных целей).
Мое общее правило при калибровке: выберите наименьший размер виртуальной машины, который может правильно выполнить работу, а затем масштабируйте/в случае необходимости. Ваш выбор в первую очередь зависит от потребностей в ЦП, ОЗУ и сети (и не забывайте, что вам нужна сеть при перемещении данных между Compute и Storage).
Еще один момент, возможно, стоит упомянуть, если вы используете четыре небольшие роли, вы сможете запускать два в одном центре данных и два в другом центре данных и использовать диспетчер трафика для маршрутизации людей, по крайней мере, ближе. Это может дать вам некоторые преимущества в производительности.
Два носителя предоставят вам больше возможностей для хранения вещей в кеше на уровне вычислений и, таким образом, больше в кеше, чем при выходе из SQL Azure, это будет быстрее.
В идеале вы должны следовать @sharptooth и измерять и тестировать. Это все очень субъективно, и я, второй Дэвид, также хочу начать как можно меньше и масштабироваться наружу. Мы запускаем этот путь, вы действительно хотите подумать о разработке своего приложения вокруг более ошеломляющего аспекта, так как это лучше подходит для лазурной модели, чем работа в традиционном смысле, просто получая большую коробку для запуска всего, в какой-то момент вы сталкиваетесь с ограничениями мышления в большем бокс-процессе, то есть, как и в случае с ограничениями на использование SQL Azure.
Использование таких технологий, как Jmeter, является вашим другом здесь и должно предоставить вам некоторые инструменты для тестирования вашего приложения.
Что вы на самом деле собираетесь принять в нем? Простой веб-сайт более сложный? Вы подключаетесь к базе данных? или какое-либо хранилище, например? – JamesKn
Его веб-сайт asp.net, разговаривающий с sql azure db. Он также использует хранилище Azure blob – Ilyas