Советы по планированию размеров и емкости и практические рекомендации - PullRequest
15 голосов
/ 13 января 2010

Меня часто просят выполнить планирование размеров и мощности для наших клиентов. Когда наши клиенты покупают наши продукты (в основном веб-приложения J2EE), они часто спрашивают, какое оборудование им понадобится для запуска этих продуктов. Наши рекомендации часто приводят к приобретению дорогостоящего оборудования.

Пока что лучшая эвристика, которую я разработал, - это сравнение прогнозов использования (количество зарегистрированных и одновременных пользователей, которые приложение должно посетить) с данными, собранными на наших существующих установках. Примерно так: если установка A обслуживает 100 одновременных пользователей с оборудованием X, то для установки B потребуется 2 * X оборудования для обслуживания 200 одновременных пользователей.

Однако этот подход имеет ряд проблем. Клиенты часто используют разные аппаратные и программные платформы. Набор продуктов, которые они покупают у нас, как правило, никогда не бывает одинаковым, и, как правило, части приложения создаются на заказ для конкретного клиента. Учтите, что версии программного обеспечения меняются и т. Д., И существует так много параметров, которые могут очень затруднить определение размера.

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

Ответы [ 3 ]

4 голосов
/ 13 января 2010

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

Я бы предложил среду виртуальных машин, где они могут легко добавлять процессор и память в зависимости от потребностей приложения в сочетании с некоторым реалистичным внешним тестированием нагрузки / масштабирования с использованием такой службы, как watchmouse или browsermob.

3 голосов
/ 14 января 2010

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

В идеале, первоначальная покупка HW / SW предназначена для пилотной установки, и вы тестируете пилотную установку, как только она запускается и соответствует спецификациям. Используйте эти результаты, чтобы спроектировать потребности в мощности для перехода от пилотного проекта к производству. Конечно, это требует времени в графике пилотного производства, чтобы сравнить приложение, затем заказать и принять поставку оборудования. Но это даст более точную оценку емкости, чем предварительная оценка.

0 голосов
/ 13 января 2010

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

...