Стандарт для этого должен был быть Измерение реакции приложения (ARM) . Это был междисциплинарный набор API, который делал именно то, что вы искали. Проблема в том, что продукты, которые реализуют эту спецификацию, как правило, являются большими, дорогими инструментами мониторинга уровня предприятия. Подумайте о многонедельных установках, консультантах, инфраструктуре и множестве модных слов.
Тем не менее, если это критически важное приложение с критическим бюджетом, это может быть то, что вам нужно. Но, возможно, вы сможете построить свой собственный, который будет достаточно просто без особых усилий. Быстрый поиск включает хотя бы одну реализацию ARM с открытым исходным кодом , если вы все еще хотите использовать этот API.
Другой вариант - просто иметь транзакции, которые вы можете запускать на каждом уровне системы, чтобы проверить общую отзывчивость. Например, у вас может быть статическая веб-страница на LB, запрет на передачу сообщений на сервере приложений, сервлет «hello» в приложении Java, размещение сообщения непосредственно в очереди и т. Д. Во время теста производительности / загрузки, они могут быть напрямую затронуты инструментом нагрузочного тестирования, или вы можете написать вызов сервлета / приложения-оболочки, который делает это как отдельный HTTP (RMI?) вызов. Запуск их несколько раз в минуту не увеличит нагрузку на систему, но поможет вам определить, какой уровень медленнее. Хорошая особенность этого подхода в том, что он также работает на производстве, просто следите за проблемами безопасности.
Для однопользовательского теста, когда вы знаете, что у вас есть проблемы (например, этот tx "медленный"), мне также очень повезло с трассировкой сети. Это очень утомительно, но когда вы не уверены, какой уровень медленный, запуск сетевой трассировки на нескольких машинах и запуск одного tx обычно дают хорошее представление о том, что делает система.