Установить причину обычно можно, если сохранились следы события: журналы приложения и сервера за нужный период, метрики, записи трассировки со сквозными идентификаторами запросов, журналы сборки мусора, дамп потоков и дамп кучи, снятые в момент проблемы, а также сведения о версии и настройках стенда. По ним эксперт восстанавливает временную шкалу и находит, где именно уходило время или что привело к отказу.
Дальше проверяются альтернативные объяснения, и это главная часть работы: код, настройки, выросший объём данных, поведение смежной системы, ограничения памяти и процессора в среде выполнения. Со стороны базы данных смотрят планы выполнения запросов, журнал медленных запросов, блокировки и состояние пула соединений. Типичные находки встречаются в каждом из этих мест: от лишних обращений к базе при обходе связанных объектов до перезапусков из-за несогласованности ограничений контейнера и параметров виртуальной машины. Воспроизведение на изолированном стенде делает вывод определённее.
Учтите, что «медленно» — не техническая категория, пока не назван измеримый критерий: какая операция, при каком объёме данных, за какое время и по какому пункту требований. Если такого критерия в договоре нет, эксперт описывает фактические показатели и их причины, а вывод о нарушении обязательств делает суд.