Java Agent Effects on Startup Performance

  • Updated

Issue

After configuring your application to use the Contrast agent, your app's startup time is degraded.

Cause

The time for an application to start up, referred to as startup performance, can be affected when Contrast is configured for assessment purposes. The startup is a crucial time for the agent, as the main operation involves analyzing libraries for reporting purposes. Many applications are affected by 20% to 30% as part of the startup cost for security analysis. Some applications can be affected by 2x to 3x depending on the number of libraries loaded and, in Java versions prior to JDK 8, the configuration of the Permanent Generation space.

Resolution

If the expected range of performance degradation is too much for your environment, or you're experiencing worse conditions, we have a few options which may help.

Increase available system resources

Applications with Contrast Agents running in Assess mode could see significant performance improvement if you can increase the RAM available to your application.  Specifically, doubling the RAM should, in most cases, yield noticeable performance improvement.

Running along side other Java agents

If Contrast will be running alongside other Java agents, like APM tools, please review our KB on configuring agents to run together.  Improper configurations with other Java agents can lead to significant delays in startup time.  

Skip Deep Inspection

The Contrast Assess product deeply inspects every piece of bytecode loaded in the JVM. This extra analysis ensures that every possible place where security-relevant functionality is occurring gets a sensor loaded. In many environments, this is not necessary. Accordingly, this deep inspection will eventually be off by default.

To enable skipping these deep inspections, add the following JVM properties:

-Dcontrast.agent.java.scan_all_classes=false
-Dcontrast.agent.java.scan_all_code_sources=false

Disabling static class scanning by setting: -Dcontrast.agent.java.scan_all_code_sources=false
Please note that this will lead to certain findings, such as those around insecure hashing, to no longer be reported.

Disabling all classes scan setting: -Dcontrast.agent.java.scan_all_classes=false
By default, the Java agent will deeply inspect all jar and war files loaded by the JVM in order to build a comprehensive understanding of the type hierarchy. Building this comprehensive understanding allows Contrast to instrument sensors into types that it might otherwise overlook. In most cases this produces a slight increase in accuracy at the cost of increased application startup time.

Run It Again

The first time Contrast runs on a new environment, or with a new version of the agent or JVM, it will perform extra code analysis as it gets loaded. The results of this analysis is cached, so the next run will have a much faster startup (50-60%).

In PaaS or Docker environments where applications are run in essentially a "factory new" setting, it's likely that there is no "previous run" from which the cached analysis can be reused. This means that every run will have the maximum startup penalty. 

The following switch can be added for java applications running in containers.  This will disable our disk caching and can improve startup times in these environments. 

-Dcontrast.assess.cache.hierarchy_enable=false 

 

Additionally: 

For spring boot applications -Dspring.main.lazy-initialization=true can be utilized to improve startup times.  See Spring Boot documentation here on that parameter. 

Class verification can also be turned off to improve startup times with the  -noverify property.  Generally this would not need to be done anyways as the compiler will not emit any invalid bytecode or class constructs.  However this is not recommended for production environments as it could avoid detection of malicious modifications to bytecode after compilation. 

 

Using -Xquickstart in the IBM JDK

Web applications leveraging the IBM JDK will experience slower-than-expected startup times. A startup option is available for the JDK to streamline the performance of startup. IBM released a JDK option -Xquickstart, which is disabled by default. Customers leveraging the IBM JDK can enable this option in their startup script and/or any location in which JVM parameters are managed (often in the WebSphere performance console). This particular JVM option causes the Just In Time (JIT) compiler to run with a subset of optimizations.

IBM -Xquickstart Overview "The effect is faster compilation times that improve startup time, but longer-running applications might run slower. When the AOT compiler is active (both shared classes and AOT compilation enabled), -Xquickstart causes all methods to be AOT compiled. The AOT compilation improves the startup time of subsequent runs, but might reduce performance for longer-running applications. -Xquickstart can degrade performance if it is used with long-running applications that contain hot methods. The implementation of -Xquickstart is subject to change in future releases. By default, -Xquickstart is disabled. Another way to specify a behavior identical to -Xquickstart is to use the -client option. These two options can be used interchangeably on the command line."

Note: Customers should test their application without Contrast enabled to ensure this option does not cause any functional instability with their application. This option has been tested by Contrast, but as stated by IBM, this option is subject to change in future releases.

 

If startup is still unmanageable after using these options, let's do a couple things that will help us isolate the problem:

Please submit a ticket and attach the results of this profiling.

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request