Определение требований к серверному оборудованию для корпоративного веб-приложения

Question

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

Адреса приложений написаны на Java и будут работать на сервере приложений Wildfly 8.0.2. Также эта новая версия приложения Ajax тяжелая, и каждый клиент может инициировать еще 5 запросов в секунду с возможностью каждого запроса открыть соединение с базой данных для извлечения данных.

В настоящее время мы не используем никаких фреймворков Java, таких как ejb или JPA, просто простая трехуровневая архитектура, основанная на сервисах. Предполагая максимальную рабочую нагрузку 200 пользователей одновременно (в качестве примера), какие ресурсы потребуются для этого? В качестве справочной информации старое приложение (после проб и ошибок) требовало около 1 ядра и 2 ГБ оперативной памяти для каждых 20 пользователей, которых я считаю. Однако на этот раз мы хотим сделать приблизительную оценку перед тестированием и настроить ее позже.

Answer 1

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

• способность обрабатывать заказы клиентов X в Y минут
• способность обслуживать до страницы Z с временем отклика < 200мс
• т.д.

После того, как ваши критерии приемки устанавливаются процесс обычно идет как это;

1. Укажите, какие вероятные шаблоны использования/пользовательские поездки.
2. Напишите несколько тестов, которые генерируют трафик, соответствующий вашим результатам от 1, а также некоторые, которые проверяют критерии приемки.
3. Запустите эти тесты на эталонном оборудовании (просто выберите что-нибудь, на самом деле не важно) с разными количествами одновременных пользователей, например 10, 100, 1000.
4. Измерьте, как изменяется время ответа с различным количеством пользователей.

У вас теперь есть контрольная точка/ориентир для производительности. Вы можете сказать, что на аппаратном обеспечении A наше программное обеспечение поддерживает число B одновременных пользователей с временем отклика в C. Вы можете расширить его для разных требований клиентов; например, если клиент оценивает двойной трафик, с которым вы тестировали, тогда вы можете захотеть иметь кластер серверов для совместной загрузки, чтобы поддерживать производительность.

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