У меня есть приложение весенней загрузки, работающее в среде k8s.
Когда я проводил несколько тестов, чтобы увидеть, как наше приложение обрабатывает множественные запросы, я заметил, что приложение теряет некоторое время до и после выполнения метода контроллера. В приложении есть несколько фильтров, которые выполняются до и после выполнения метода контроллера, но они не делают ничего серьезного, а просто считывают некоторую информацию из запросов и удаляют некоторые кэшированные строки.
У меня есть настройки трассировки, поэтому я могу отслеживать выполнение определенных частей приложения, в основном внешних вызовов, но в целях тестирования я добавил трассировку в дополнительные части. Корневой диапазон трассировки запускается в фильтре, который находится в верхней части цепочки фильтров.
Вы можете увидеть странное поведение на изображении трассировок ниже.
Красным я отметил диапазоны, которые представляют методы контроллера, черным я отметил диапазоны, которые представляют диапазоны двух последних фильтров, которые расположены в конце цепочки фильтров.
На этом изображении мы видим, что после taas_tenant_support_check fitler, который является вторым с последнего в цепочке фильтров завершилось выполнение, выполнение метода контроллера началось через 50 мс.
На этом изображении мы видим, что фильтр taas_remove_bo_user_context, который является последним в цепочке фильтров, был выполнен примерно через 80 мс после завершения выполнения метода контроллера.
Это поведение было зафиксировано только во время работы приложения в среде k8s на моем локальном компьютере с той же нагрузкой (которая в настоящее время составляет всего 50 мс). параллельные запросы) такого никогда не происходит.
Под, в котором работает наше приложение, использует максимум 1 ЦП и 2 ГБ памяти.
Я также запускал приложение на своем локальном компьютере внутри Docker-контейнера с аналогичными ограничениями ресурсов, но странное поведение не было зафиксировано.
Промежутки трассировки экспортируются пакетами, и этот экспортер работает в отдельном потоке от основного приложения, и я не думаю, что это нас замедляет. вниз.
С помощью отладчика я просмотрел исходный код Spring, чтобы увидеть, что происходит до и после выполнения метода контроллера, но я не нашел ничего, что могло бы вызвать такое поведение.
Есть ли у кого-нибудь идеи, что здесь может происходить?
