Назад |
Перейти на главную страницу
Как найти пределы кластерного Tomcat с репликацией сеанса
Я работаю над кластером Tomcat экспериментально, потому что он может понадобиться нам в производственной среде. Он должен быть масштабируемым, высокодоступным и поддерживать как можно больше одновременных пользователей. Поэтому я сделал такую тестовую среду:
HaProxy
/ \
/ \
Tomcat 1 (7.0) Tomcat 2(7.0)
Redis 1 Redis 2
Tomcats балансируют нагрузку на HaProxy и реплицируют свои сеансы через Redis. Каждый Redis связывался друг с другом через дозорных. Наконец, каждый пакет Tomcat и Redis - это машина. Например, Tomcat 1 и Redis 1 находятся на одном сервере.
В конце этой экспериментальной лаборатории у меня есть несколько вопросов,
- Как я могу расширить границы этой лаборатории? Я пробовал использовать базовые приложения на tomcat, но мне нужно знать ограничения этого кластера, чтобы обнаружить потенциальные точки переключения при отказе.
- Каковы потенциальные недостатки этой лаборатории? Каковы лучшие практики по одним и тем же вопросам?
- В чем преимущества или недостатки использования Web Logic или Wildfly вместо Tomcat или использования DeltaManager или BackupManager по умолчанию Tomcat?
- Я хочу попробовать воспроизвести воспоминания узлов друг другу. Является ли это возможным? Если есть возможность, хочу узнать ваши рекомендации :)
Заранее спасибо.
Вам нужно сосредоточиться на тестировании вашего приложения, а не на тестировании Tomcat (или любого другого сервера приложений).
Процесс обнаружения предела прочности тестируемой системы известен как нагрузочное тестирование, идея заключается в следующем:
- Используя инструмент нагрузочного тестирования создать рабочую нагрузку, которая будет представлять обычный сценарий (-ы) использования приложения
- Настроить мониторинг базовых показателей здоровья JVM где работает Tomcat и базовая операционная система.
- Начните с 1 виртуального пользователя и постепенно увеличивайте нагрузку, следя за потреблением системных ресурсов.
- Когда какой-либо из показателей потребления ресурсов системы (ЦП, ОЗУ, сеть / дисковый ввод-вывод) превысит, т.е. 90% максимальной доступной емкости, или система начнет подкачку, или JVM будет часто выполнять сборку мусора, или время отклика приложения начнет превышать допустимые пороговые уровни или начнут появляться ошибки - это так называемое
"bottleneck"
и это количество одновременных пользователей (или запросов в секунду), которое может обслуживать ваше приложение.