Как найти пределы кластерного 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 находятся на одном сервере.

В конце этой экспериментальной лаборатории у меня есть несколько вопросов,

  1. Как я могу раздвинуть границы этой лаборатории? Я пытался использовать базовые приложения на tomcat, но мне нужно знать пределы этого кластера, чтобы обнаружить потенциальные точки сбоя.
  2. Каковы потенциальные слабости этой лаборатории? Каковы лучшие практики по тем же вопросам?
  3. Каковы преимущества или недостатки использования Web Logic или Wildfly вместо Tomcat или использования DeltaManager или BackupManager по умолчанию для Tomcat?
  4. Я хочу попробовать скопировать узлы памяти друг другу. Является ли это возможным? Если возможно, я хочу знать ваши рекомендации:)

Заранее спасибо.

1 ответ

Вы должны сосредоточиться на тестировании своего приложения, а не на тестировании Tomcat (или любого другого сервера приложений).

Процесс обнаружения критической точки тестируемой системы известен как стресс-тестирование, идея заключается в следующем:

  1. Используя инструмент нагрузочного тестирования, создайте рабочую нагрузку, которая будет представлять сценарии нормального использования приложения.
  2. Настройте мониторинг базовых показателей работоспособности JVM, на котором запущен Tomcat и в операционной системе.
  3. Начните с 1 виртуального пользователя и постепенно увеличивайте нагрузку, одновременно следя за потреблением системных ресурсов.
  4. Когда какой-либо из показателей потребления системных ресурсов (ЦП, ОЗУ, сетевой / дисковый ввод-вывод) будет превышен, т. Е. 90% от максимальной доступной емкости или система начнет подкачку, или JVM будет часто выполнять сборку мусора, или время отклика приложения начнет превышать допустимые пороговые уровни. или ошибки начнут появляться - это так называемый "bottleneck" и это количество одновременно работающих пользователей (или запросов в секунду), которое может обслуживать ваше приложение.
Другие вопросы по тегам