|License Type||SaaS & On-Premise|
|Agent Mode||Assess & Protect|
|Main Product Category||Java Agent|
After configuring your application to use the Contrast agent, your app's startup time is degraded.
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.
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.
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:
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.
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:
- Get Contrast startup profile information. The agent can be configured to dump startup profile information to stdout. To enable this, pass the following JVM option alongside your
-Dcontrast.agent.java.report_startup_metrics=trueNOTE: This flag captures timing information and shows it in the application's stdout, not the contrast.log, because the information captured by this flag includes things that happen even before anything is written to contrast.log.
- Record a full profile of the application startup with Contrast following these steps: How to generate a YourKit session
Please submit a ticket and attach the results of this profiling.