Стресс-тестирование системы на основе распределенной архитектуры SOA

В настоящее время у нас есть система с 20 службами SOA, одной главной базой данных mysql и двумя подчиненными узлами. В настоящее время у нас есть 10 ГБ данных в базе данных. У нас есть требование, при котором данные в таблице будут значительно увеличены. Мы хотим провести стресс-тестирование системы, прежде чем приступить к реализации. Какое стресс-тестирование имеет смысл для такой распределенной среды?

Кроме того, при выполнении стресс-тестирования я могу следить за задержкой и такими показателями, как задержка для обслуживания 90% запросов к службам. Есть ли другие хорошие показатели для услуг? Какие показатели следует искать для базы данных mysql?

Спасибо


database testing performance metrics stress-testing
person Boolean    schedule 05.06.2010    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Вот несколько идей:

  1. Настройте тестовую базу данных и загрузите дополнительные данные в таблицу, где вы ожидаете увеличения; используйте кратное увеличение, которое вы ожидаете, например, если вы ожидаете, что таблица увеличится на 2000 строк, добавьте 4000 строк в тестовую таблицу.
  2. Включите медленное ведение журнала запросов в MySQL.
  3. Убедитесь, что уровни ведения журналов на ваших серверах SOA достаточно подробны, чтобы отлаживать ошибки стресс-теста.
  4. Используйте инструмент нагрузочного тестирования, такой как JMeter, чтобы запустить несколько запросов к каждой службе в быстрой последовательности. Используйте кратное ожидаемому количеству запросов в секунду; Обычно я увеличиваю число ожидаемых запросов в 2, 4, 8 и т. д. раз.
  5. Повторите вышеуказанный тест для каждой отдельной службы по очереди.
  6. Повторите приведенный выше тест с «типичным» набором услуг, например. если вы ожидаете вдвое больше запросов к сервису 1, чем к сервису 2, отразите это в тесте.
  7. Если вы также хотите проверить надежность, попробуйте повторить тесты JMeter с одним или обоими подчиненными узлами MySQL, отключенными от сети.

JMeter должен предоставить вам всю необходимую информацию о задержке. Еще одна полезная точка данных «реального мира» из JMeter, которую мне нравится использовать, — это 90% времени запроса, то есть значение времени ответа, которое больше или равно 90% тестовых ответов.

person gareth_bowles    schedule 05.06.2010

arrow_upward
1
arrow_downward

Идея в этом сценарии по-прежнему состоит в том, чтобы попытаться смоделировать запросы страниц и сообщения по мере их использования в рабочей среде. Разница заключается в том, чтобы запустить нагрузочный тест только с копией 10 ГБ текущих производственных данных. Затем смоделируйте дополнительные данные и запустите тот же нагрузочный тест. Вы сможете сравнить ответы страниц, которые используют услуги, или проверить вызовы службы напрямую.

Затем вы можете увидеть, как дополнительные данные повлияют на ваши обращения в службу поддержки.

Метрики, которые являются наиболее важными, — это время ответа для вызовов, которые, как вы ожидаете (или измеряли), будут вызываться наиболее часто.

Другие статистические данные о базе данных и самих серверах могут быть проанализированы, если вы обнаружите проблему с производительностью.

person Nat    schedule 14.06.2010