Optimizing Applications​

Profiling​

To minimize overhead at runtime,monitoring information is gathered rather on a global application level and hence might not be sufficient to troubleshoot specific issues. In such a situation, the use of more focused profiling tools can be an option. Typically, such tools can focus on a specific aspect of an application (for instance CPU or Memory management), but they come with an additional overhead and should only be enabled when needed. Hence, they need to meet the following requirements:

• Switchable at runtime
• Use a communication channel not exposed to unauthorized users
• Not interfering or even blocking business requests

How can dedicated Java tools access the running services in a secure manner? The depicted diagram shows recommended options thatdo not require exposed HTTP endpoints:

As an authorized operator, you can access the container and start toolslocally in a CLI session running with the same user as the target process. Depending on the protocol, the JVM supports on-demand connections, for example, JVM diagnostic tools such asjcmd. Alternatively, additional JVM configuration is required as a prerequisite (JMX).

Local Tools​

Various CLI-based tools for JVMs are delivered with the SDK. Popular examples arediagnostic tools such asjcmd,jinfo,jstack, andjmap, which help to fetch basic information about the JVM process regarding all relevant aspects. You can take stack traces, heap dumps, fetch garbage collection events and read Java properties and so on. The SAP JVM comes with additional handy profiling tools:jvmmon andjvmprof. The latter, for instance, provides a helpful set of traces that allow a deep insight into JVM resource consumption. The collected data is stored within aprf-file and can be analyzed offline in theSAP JVM Profiler frontend.

Remote JMX-Based Tools​

Java's standardized frameworkJava Management Extensions (JMX) allows introspection and monitoring of the JVM's internal state via exposed Management Beans (MBeans). MBeans also allow to trigger operations at runtime, for instance setting a logger level. Spring Boot automatically creates a bunch of MBeans reflecting the currentSpring configuration and metrics and offers convenient ways for customization. To activate JMX in Spring, add the following property to your application configuration.:

spring.jmx.enabled: true

In addition, to enable remote access, add the following JVM parameters to open JMX on a specific port (for example, 5000) in the local container:

-Djava.rmi.server.hostname=localhost-Dcom.sun.management.jmxremote-Dcom.sun.management.jmxremote.port=<port>-Dcom.sun.management.jmxremote.rmi.port=<port>-Dcom.sun.management.jmxremote.authenticate=false-Dcom.sun.management.jmxremote.ssl=false

To establish a connection with a remote JMX client, first open an ssh tunnel to the application viacf CLI as operator user:

cf ssh -N -T -L <local-port>:localhost:<port> <app-name>

Afterwards, connect tolocalhost:<local-port> in the JMX client. Common JMX clients are:

• JConsole, which is part of the JDK delivery.
• OpenJDK Mission Control, which can be installed separately.

GraalVM Native Image Supportbeta​

Since Spring Boot 3 it's possible to compile Spring Boot applications to stand-alone native executables leveraging GraalVM Native Images. Native Image applications have faster startup times and require less memory. CAP Java provides compatibility with the Native Image technology.

Learn more about Native Image support in Spring Boot.

If you want to compile your application as a native executable the following boundary conditions need to be considered:

1. The GraalVM Native Image build analyzes your application from themain entry point. Only the code that is reachable through static analysis is included into the native image. This means that the full classpath needs to be known and available already at build time.

2. Dynamic elements of your code, such as usage of reflection, JDK proxies, or resources need to be registered with the GraalVM Native Image build. You can learn more about this in theGraalVM Native Image documentation.

   TIP

   Many runtime hints for reflection, JDK proxy usage, and resources are contributed automatically to the Native Image build. This includes

   • Required reflection for event handler classes defined in application code.
   • JDK proxies for interfaces generated from the application's CDS model by the CDS Maven Plugin.

3. Spring Boot automatically defines and fixes all bean definitions of your application at build time. If you have bean definitions that are created based on conditions on externalized configuration or profiles, you need to supply these triggers to the Native Image build.

   CAP Java also creates various bean definitions based on service bindings. Therefore, you need to provide the metadata of expected service bindings at runtime already during build time. This is similar to the information you define in deployment descriptors (for examplemta.yaml or Helm charts). This information is also required to be supplied to the Native Image build.

   The Spring Boot Maven Plugin allows you toconfigure the Spring profiles that are used during the Native Image build. You can supply information to the Native Image Build in anative-build-env.json, which you can configure together with the Spring profile. For example you can provide information to the Native image build in thenative-build-env.json which you can configure together with the spring profile in thesrv/pom.xml:

   native-build-env.jsonsrv/pom.xml

   json

   {    "hana": [ {"name":"<hana-binding-name>" } ],    "xsuaa": [ {"name":"<xsuaa-binding-name>" } ]}

   xml

   <profile>    <id>native</id>    <build>        <pluginManagement>            <plugins>                <plugin>                    <groupId>org.springframework.boot</groupId>                    <artifactId>spring-boot-maven-plugin</artifactId>                    <executions>                        <execution>                            <id>process-aot</id>                            <configuration>                                <profiles>cloud</profiles>                                <jvmArguments>-Dcds.environment.local.defaultEnvPath=../native-build-env.json</jvmArguments>                            </configuration>                        </execution>                    </executions>                </plugin>            </plugins>        </pluginManagement>    </build></profile>

When using Spring Boot's parent POM, you can easily trigger the Native Image build by executingmvn spring-boot:build-image -Pnative. This builds a Docker image using Cloud Native Buildpacks including a minimized OS and your application. You can launch the Docker image by runningdocker run --rm -p 8080:8080 <srv-project-name>:<version>.