What has Jetty been running for a long time?

Jetty launch there is a long delay (8s) before my web application starts downloading

13:50:10 [INFO] jetty-9.4.5.v20170502 13:50:18 [INFO] Scanning elapsed time=146ms 

When you enable debug logging, there are two interesting steps

  • Retrieving a dependent military application that takes all the time (3s)

     10:03:13 [DEBUG] Extracting entry = null from jar file:[..]/application-1.0.war 10:03:16 [DEBUG] Unpacked overlay: jar:file:[..]/application-1.0.war!/ to file:[..] 
  • and delay below 4s:

     10:03:16 [DEBUG] Service loaders found in 0ms 10:03:20 [DEBUG] loaded interface javax.servlet.ServletContainerInitializer 

How can I debug or influence what causes a delay above 4s?


Configuration

pom.xml

 <dependency> <groupId>com.company</groupId> <artifactId>application</artifactId> <version>1.0</version> <type>war</type> </dependency> [...] <plugin> <groupId>org.eclipse.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <version>9.4.5.v20170502</version> <configuration> <webApp> <webInfIncludeJarPattern>empty</webInfIncludeJarPattern> <containerIncludeJarPattern>empty</containerIncludeJarPattern> </webApp> </configuration> </plugin> 

web.xml

 <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" version="3.1" metadata-complete="true"> <context-param> <param-name>contextClass</param-name> <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value> </context-param> <context-param> <param-name>contextConfigLocation</param-name> <param-value>com.app.AnnotationConfig</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> [...] </web-app> 
+5
source share
1 answer

You have a larger than average webapp (70 MB in WEB-INF / lib banks), but nothing is colossally large (I saw 800MB of military files)

There are several things that can cause a slowdown.

  • Unpacking war into temp webapp directory
  • Unpacking resource containers ( WEB-INF/lib/*.jar!/META-INF/resources/ ) into the temp WebApp directory
  • Scan Jar bytecode (for annotations and types declared in @HandlesType annotations in javax.servlet.ServletContainerInitializer classes)

If your file system is slow, then any of the above can slow down.

Note: registering in the DEBUG Jetty magazine will inform you of the timing of each of them (even by canceling the synchronization time of the bytecode scan to a separate bank)

The bytecode scan rate is the most common place where startup time takes a hit.

Configuring <containerIncludeJarPattern> for "empty" is not recommended, which is necessary for servlets, JSP, Taglib to work.

containerIncludeJarPattern by default is only servlet banks / jsp / taglib. (which require scanning microseconds)

<webInfIncludeJarPattern> also should not be just "empty", it should at least include your WEB-INF/classes content (aka .*/classes/.* ). Think about tuning to check only those WEB-INF/lib banks that you need. (something like .*/lib/spring-.*\.jar$|.*/classes/.* )

The size in bytes of the classes in your WEB-INF/lib/*.jar and WEB-INF/classes does not actually matter. More important for synchronization is the number of files found (even non-classical files).

If you use resource banners ( WEB-INF/lib/*.jar!/META-INF/resources/ ), then this is a significant penalty / source of slow startup.

What can you do:

Start by looking at DEBUG magazines that tell you where things take their time.

Then examine with the quickstart Jetty functions if launch time is important (this has 2 parts, a build time component that scans and builds jetty-quickstart.xml , which is included in your war, and a run time module that looks for and uses jetty-quickstart.xml if found)

Finally, if you use resource banks ( WEB-INF/lib/*.jar!/META-INF/resources/ ), consider moving content from WEB-INF/lib to the usual places in your war during assembly ( package phase in maven). They are convenient, but have a bunch of side effects that you don't like. (also consider conflicting resolution of resources at runtime).

+2
source

Source: https://habr.com/ru/post/1270714/


All Articles