Советы по планированию размеров и емкости и практические рекомендации
Меня часто просят выполнить расчет размеров и мощности для наших клиентов. Когда наши клиенты покупают наши продукты (в основном веб-приложения J2EE), они часто спрашивают, какое оборудование им понадобится для запуска этих продуктов. Наши рекомендации часто приводят к приобретению дорогостоящего оборудования.
Пока что лучшая эвристика, которую я разработал, - это сравнение прогнозов использования (количество зарегистрированных и одновременных пользователей, которые приложение должно посещать) с данными, собранными на наших существующих установках. Примерно так: если установка A обслуживает 100 одновременно работающих пользователей с оборудованием X, то для установки B потребуется 2*X оборудования для обслуживания 200 одновременных пользователей.
Этот подход, однако, имеет ряд проблем. Клиенты часто используют разные аппаратные и программные платформы. Набор продуктов, которые они покупают у нас, как правило, никогда не бывает одинаковым, и, как правило, части приложения создаются на заказ для конкретного клиента. Помните, что версии программного обеспечения меняются и т. Д., И существует так много параметров, которые могут очень затруднить определение размера.
Я изучил некоторые книги по этой теме, а некоторые предлагают использовать сложные математические модели. Количество параметров, которые эти подходы требуют в качестве входных данных (например, детальная классификация функций приложения), заставляет меня думать, что они вряд ли полезны. Аппаратное обеспечение обычно заказывается еще до того, как определены основные требования, не говоря уже о том, что они будут различаться на протяжении всей разработки приложений и жизненного цикла. Итак, как вы оцениваете размеры и планирование мощностей? Любые советы и рекомендации приветствуются.
3 ответа
Если оборудование необходимо заказать до того, как будут определены основные требования, самое лучшее, что вы можете сделать, - это приблизить пропускную способность, посмотрев на установленную базу аналогичный набор проектов (как вы делаете сейчас). Следите за тем, как ваши существующие клиенты испытывают потребности в масштабировании и емкости по мере роста их установок, и, если у вас достаточно большая база, вы, вероятно, сможете выполнить грубую кривую подгонки, сгруппировав аналогичные проекты с аналогичным оборудованием и изучив потребности в емкости. Посмотрите, как изменяются потребности существующих клиентов в процессе роста, а также дополнительные точки данных.
В идеале, первоначальная покупка HW/SW предназначена для пилотной установки, и вы тестируете пилотную установку, как только она запускается и соответствует спецификациям. Используйте эти результаты, чтобы спроектировать потребности в мощности для перехода от пилотного проекта к производству. Конечно, это требует времени в графике пилотного производства, чтобы сравнить приложение, затем заказать и принять поставку оборудования. Но это даст более точную оценку емкости, чем предварительная оценка.
В приведенном вами описании нет простой или математической формулы для прогнозирования масштаба, если вы (или ваша компания) серьезно относитесь к этому, тогда лучший способ - создать среду тестирования производительности и масштабируемости, в которой вы можете легко настроить и отключить различных клиентов. конфигурации и отправьте на них нагрузку, чтобы посмотреть, как они будут работать. Поскольку вы создаете пользовательские компоненты, один плохо написанный компонент или отсутствующий индекс может все испортить, поэтому в такой среде вы можете сгладить все эти вещи перед тем, как передать их клиенту. Если у вас есть среда такого типа, вы можете добавить память и процессор к серверам приложений и базам данных, чтобы увидеть, как масштабируется ваше приложение.
Я бы предложил среду виртуальных машин, в которой они могут легко добавлять процессор и память в зависимости от потребностей приложения в сочетании с некоторым реалистичным внешним тестированием нагрузки / масштабирования с использованием службы, такой как watchmouse или browsermob.
Если приложение изящно масштабируется по горизонтали, в качестве отправной точки можно использовать приблизительную начальную оценку. Добавление или удаление дополнительных блоков по мере необходимости должно быть простым после запуска приложения в производство.