Планирование мощностей - довольно подробная и обширная область. Вам нужно будет принять итеративную модель с подходом «Теоретическая база> Нагрузочное тестирование> Настройка и оптимизация».
Теория
Первым шагом является определение бизнес-требований: сколько пользователей ожидается при пиковой нагрузке? Помните - эти цифры, как правило, неточны.
В качестве примера, давайте предположим, что весь пиковый трафик (в худшем случае) будет занимать более 4 часов дня. Поэтому, если веб-сайт ожидает 100 тыс. Посещений в день, мы не делим это на 24 часа, а вместо этого - на 4 часа. Так что мой сайт теперь должен поддерживать пиковый трафик в 25 тыс. Посещений в час.
Это разбивает до 417 ударов в минуту, или 7 ударов в секунду. Это только на переднем конце.
Добавьте к этому количество внутренних транзакций, таких как операции с базой данных, любой файловый ввод / вывод на пользователя, любые пакетные задания, которые могут выполняться в системе, отчеты и т. Д.
Подсчитайте все это, чтобы получить количество транзакций в секунду, минуту и т. Д., Которое ваша система должна поддерживать.
Это усложняется, когда у вас есть такие требования, как «Среднее время ответа должно составлять 3 секунды и т. Д.», Что означает, что вы должны указать сетевую задержку / межсетевой экран / прокси и т. Д.
Наконец - когда дело доходит до выбора оборудования, посмотрите опубликованные таблицы данных от каждого производителя, такого как Sun, HP, IBM, Windows и т. Д. В них подробно описывается максимальное количество транзакций в секунду в условиях тестирования. Обычно мы принимаем 50% этих пиков в реальных условиях:)
Но в конечном итоге выбор аппаратного обеспечения обычно является коммерческим решением.
Также для каждого отказоустойчивого кластера необходимо хранить как минимум 2 сервера: web / app / даже db.
нагрузочное тестирование
Рекомендуется иметь отдельную среду эталонного тестирования на протяжении всего жизненного цикла проекта и после запуска, чтобы вы могли вернуться и запустить специальные тесты производительности в приложении. Масштабируйте его, чтобы он был уменьшенной версией производства, поэтому, если в Prod есть 4 сервера, а в Ref - 1, вы проверяете 25% пиковых транзакций и т. Д.
Настройка и оптимизация
Слишком часто люди собирают какое-то дорогое оборудование и ожидают, что все будет прекрасно работать. Вам нужно будет настроить оборудование и ОС для различных параметров, таких как тайм-ауты TCP и т. Д. - они публикуются поставщиками программного обеспечения, и это необходимо сделать после завершения разработки программного обеспечения. Установите эти параметры настройки в Ref env, протестируйте, а затем решите, какие из них вам нужно перенести в Production.