title: Performance - Spring Boot - Server Response Time
body: <p>I have a strange behaviour on our spring boot application:</p>
  
  <ul>
  <li>Frontend/Client - angular 6</li>
  <li>Backend - spring boot - spring MVC - embedded tomcat - Linux</li>
  </ul>
  
  <p>After restarting the backend the first calls to a controller needs about 5 seconds, the following same request only takes 50ms. This is reproducible in 90% of the cases, sometimes even the first call is fast.</p>
  
  <p>I am sure, the problem is on the server not on the client. On the browser, I see the TTFB time (time to the first byte) is increasing to 5 seconds. The following requests only need 10ms for TTFB.</p>
  
  <p>With monitoring tools on the server (app dynamics) i can collect such slow server calls and on the call graph i can see that:</p>
  
  <pre><code>org.apache.catalina.webresources.JarWarResourceSet:getArchiveEntries:117
  </code></pre>
  
  <p>needs 4916ms. So here is my bottleneck, I think. But I don't know how to fix it.</p>
  
  <p>What i have already tryed:</p>
  
  <ul>
  <li>Switched from hikaricp to apache tomcat jdbc connection pool</li>
  <li>Ugraded spring boot from 2.0.0 to 2.0.5</li>
  <li>Upgraded java to 1.8.0_181</li>
  <li>Propertie spring.jpa.tomcat.testOnBorrow = true</li>
  <li>Propertie spring.jpa.tomcat.validationQuery = select 1</li>
  </ul>
  
  <p>Everything without influence to the server delay.</p>
  
  <p><strong>Update</strong></p>
  
  <p>The time is lost cause the war file is scanned multiple times.</p>
  
  <p><em>org.apache.catalina.webresources.CachedResource.validateResource</em> is checking if we have a war file (<em>isPackedWarFile</em>) and this check return false. Even though it is a war file. For this misbehave I have a workaround. I set <em>tomcat.resource.cache-tt</em> to a high value. </p>
  
  <p>But now <em>org.apache.catalina.webresources.Cache.getResource</em> has a <em>noCache</em> method. And in this method <em>class</em> and <em>jar</em> files are excluded from caching. And this is the reason why the <em>war</em> file is scanned again.</p>
  
  <p>Scanning the whole war file takes roughly 5 seconds. And this break is a stop the world break. And this scanning is absolutely needless cause the war file is not exploded and so its contents can not be changed.</p>
  
  <p><strong>Update</strong></p>
  
  <p>If I put the war file into a tomcat installation everything is fast. The embedded tomcat is the problem.</p>