У меня странное поведение в нашем весеннем загрузочном приложении:
- Frontend/Client - угловой 6
- Backend - весенний ботинок - весна MVC - встроенный tomcat - Linux
После перезапуска бэкэнд первым вызовам контроллера требуется около 5 секунд, следующий запрос будет занимать только 50 мс. Это воспроизводится в 90% случаев, иногда даже первый вызов выполняется быстро.
Я уверен, проблема на сервере не на клиенте. В браузере я вижу, что время TTFB (время до первого байта) увеличивается до 5 секунд. Следующие запросы требуют только 10 мс для TTFB.
С инструментами мониторинга на сервере (динамика приложений) я могу собирать такие медленные вызовы сервера, а на графике вызовов я вижу, что:
org.apache.catalina.webresources.JarWarResourceSet:getArchiveEntries:117
требуется 4916 мс. Так вот, вот мое узкое место, я думаю. Но я не знаю, как это исправить.
Что я уже пробовал:
- Переключено с hikaricp в пул соединений apache tomcat jdbc
- Ugraded spring boot от 2.0.0 до 2.0.5
- Обновлен java до 1.8.0_181
- Propertie spring.jpa.tomcat.testOnBorrow = true
- Propertie spring.jpa.tomcat.validationQuery = выберите 1
Все без влияния на задержку сервера.
Обновить
Время утеряно, потому что файл войны сканируется несколько раз.
org.apache.catalina.webresources.CachedResource.validateResource проверяет, есть ли у нас файл войны (isPackedWarFile), и эта проверка возвращает false. Хотя это военный файл. Для этого плохого поведения у меня есть обходное решение. Я установил tomcat.resource.cache-tt в большое значение.
Но теперь org.apache.catalina.webresources.Cache.getResource имеет метод noCache. И в этом методе класс и файлы jar исключаются из кеширования. И вот почему файл войны снова проверяется.
Сканирование всего файла войны занимает примерно 5 секунд. И этот перерыв - это остановка мировой паузы. И это сканирование абсолютно бесполезно, потому что файл войны не взорван и поэтому его содержимое не может быть изменено.
Обновить
Если я поместил файл войны в установку tomcat, все будет быстро. Проблема с встроенным tomcat.