Как найти пределы кластерного 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?
- Я хочу попробовать скопировать узлы памяти друг другу. Является ли это возможным? Если возможно, я хочу знать ваши рекомендации:)
Заранее спасибо.
1 ответ
Вы должны сосредоточиться на тестировании своего приложения, а не на тестировании Tomcat (или любого другого сервера приложений).
Процесс обнаружения критической точки тестируемой системы известен как стресс-тестирование, идея заключается в следующем:
- Используя инструмент нагрузочного тестирования, создайте рабочую нагрузку, которая будет представлять сценарии нормального использования приложения.
- Настройте мониторинг базовых показателей работоспособности JVM, на котором запущен Tomcat и в операционной системе.
- Начните с 1 виртуального пользователя и постепенно увеличивайте нагрузку, одновременно следя за потреблением системных ресурсов.
- Когда какой-либо из показателей потребления системных ресурсов (ЦП, ОЗУ, сетевой / дисковый ввод-вывод) будет превышен, т. Е. 90% от максимальной доступной емкости или система начнет подкачку, или JVM будет часто выполнять сборку мусора, или время отклика приложения начнет превышать допустимые пороговые уровни. или ошибки начнут появляться - это так называемый
"bottleneck"
и это количество одновременно работающих пользователей (или запросов в секунду), которое может обслуживать ваше приложение.