Я работаю над корпоративным java приложением, в котором уже есть много инструментов / сред, таких как Struts, JAX-RS и Spring MVC. Он содержит пользовательский интерфейс и конечные точки REST, объединенные в файл .war. Проект развивается, и мы избавляемся от старых инструментов, стремясь придерживаться только Spring MVC / Webflux.
Приложение выполняет поиск по миллионам записей XML / JSON, и недавно поисковая система была переключена от Marklogi c до Elasticsearch.
Что мы заметили, так это то, что при работе с не столь интенсивным использованием (до 1,7 тыс. об / мин на 2-4 узлах приложения) время отклика на некоторых из конечных точек увеличивается в течение время. Elasticsearch имеет пространство для роста и не показывает никаких признаков огромной нагрузки. Поэтому в настоящее время мы должны перезапускать / заменять экземпляры продукта один раз в неделю или две, когда среднее время ответа превышает 3 секунды вместо обычных 200-300 миллис .
Я пытался получить графики пламени процессора и кучи, используя asyn c -profiler , но профиль нагрузки меняется при каждом измерении, так как у нас есть куча доступных функций, поэтому я не могу действительно сравнить, как меняются графики время.
Можете ли вы посоветовать мне некоторые тактики / подходы для поиска подходящего места в коде?