Советы по калибровке и настройке емкости и рекомендации

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

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

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

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

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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