Назад | Перейти на главную страницу

Как найти пределы кластерного 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. Я хочу попробовать воспроизвести воспоминания узлов друг другу. Является ли это возможным? Если есть возможность, хочу узнать ваши рекомендации :)

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

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

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

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