Стресс-тестирование на распределенный SOA основанная на архитектуре Система
У нас в настоящее время есть система с 20 услугами SOA и наличием единственной основной mysql базы данных и 2 ведомых узлов. У нас в настоящее время есть 10 ГБ данных в базе данных. У нас есть требование, в котором данные в таблице значительно будут увеличенными. Мы хотим к стресс-тесту систему перед продолжением реализации. Какое стресс-тестирование имеет смысл для этого вида распределенной среды?
Кроме того, при выполнении стресс-тестирования я могу высматривать задержку и метрики как то, что является задержкой для обслуживания 90% запросов на сервисы. Есть ли какие-либо другие хорошие метрики для сервисов? Какие метрики я должен искать mysql базу данных?
Спасибо
2 ответа
Вот несколько идей:
- Создайте тестовую базу данных и загрузите дополнительные данные в таблицу, в которой вы ожидаете увеличения; используйте кратное ожидаемому увеличение, например, если вы ожидаете, что таблица увеличится на 2000 строк, добавьте 4000 строк в тестовую таблицу.
- Включите логирование медленных запросов в MySQL.
- Убедитесь, что уровни протоколирования на серверах SOA достаточно подробны для отладки ошибок стресс-теста.
- Используйте инструмент нагрузочного тестирования, такой как JMeter, для выполнения нескольких запросов к каждой службе в быстрой последовательности. Используйте число запросов в секунду, кратное ожидаемому; я обычно увеличиваю нагрузку в 2, 4, 8 и т.д. раз по сравнению с ожидаемым числом запросов.
- Повторите вышеуказанный тест с каждой отдельной службой по очереди.
- Повторите вышеуказанный тест с "типичным" сочетанием сервисов - например, если вы ожидаете, что количество запросов к сервису 1 будет в два раза больше, чем к сервису 2, отразите это в тесте.
- Если вы хотите также проверить надежность, попробуйте повторить тесты JMeter с одним или обоими подчиненными узлами MySQL, отключенными от сети.
JMeter должен дать вам всю необходимую информацию о задержке. Еще один полезный показатель "реального мира" в JMeter, который я люблю использовать, - это 90% времени запроса, то есть значение времени ответа, которое больше или равно 90% тестовых ответов.
Идея этого сценария по-прежнему состоит в том, чтобы попытаться смоделировать запросы и публикации страниц, как они используются в производственной среде. Разница заключается в том, чтобы запустить нагрузочный тест с копией 10 ГБ текущих производственных данных. Затем смоделируйте дополнительные данные и запустите тот же нагрузочный тест. Вы сможете сравнивать ответы страниц, использующих сервисы, или напрямую проверять обращения к сервисам.
Затем вы можете увидеть, как дополнительные данные повлияют на ваши обращения в службу поддержки.
Наиболее важными показателями являются время отклика на звонки, которые, как вы ожидаете (или измерили), будут выполняться наиболее часто.
Другие статистические данные о базе данных и самих серверах можно проанализировать, если вы обнаружите проблемы с производительностью.