Improving Java application performance

This section describes some changes that can be made to improve the performance of Java™ applications on the systems that are based on zPDT®. Some changes are implemented as follows. You can refer to the following examples for other applications.

The Java application performance can be improved by using some tuning options and a persistent Java cache that can even speed up to restart the complete system.

Improving the performance with Java cache and tuning options

Java cache can significantly speed up the startup of applications and improve the application performance for repeated workloads. The Java cache structures are populated when an application process is executed. Therefore, the benefits of the cache are not experienced until the subsequent and similar processes are executed. Some z/OS® subsystems heavily rely on Java. With ZD&T-based ADCD, the following z/OS subsystems use a persistent Java cache.
  • z/OS Explorer
  • RSE API
    Note: RSE API shares the cache with z/OS Explorer.
  • Dependency Based Built (Personal and Shared Daemons)
  • z/OS Connect EE
  • z/OS Management Facility
  • UrbanCode® Deploy
  • Debug Profile Service
The following Java tuning options are recommended:
  • Xms256m
  • Xmx512m
  • Xquickstart
  • Xshareclasses:nonFatal
  • Xshareclasses:groupAccess
  • Xshareclasses:cacheDirPerm=0777
  • Xscmx50m
  • Xshareclasses:cacheDir=/javasc/xxx,name=yyy
    Note: For the values of xxx and y, see the details of JACHER REXX that are described in the JCACHER.
  • Xlp:objectheap:pagesize=1m,warn,pageable
  • Xlp:codecache:pagesize=1m,pageable
The following Java tuning option need to be avoided.
  • Xtune:virtualized

    This option was removed from the default CICS® WebSphere® Liberty profile because this option caused negative impact to the Liberty startup.

Persisting Java cache

The Java cache is stored in the memory. To persist the Java cache and obtain the benefits during the restart process, the cache must be saved to a file system, and then be restored back to the memory in the early process of z/OS startup. Some automation was built by using NetView®, REXX, and a UNIX System Services file system.

The following NetView tasks are included:
RESTCASH
Process to restore the cache in the memory when a z/OS system is started.
JCACHER
General utility to manage the Java cache. JCACHER utility is running during system shutdown to back up the cache in the memory to a UNIX System Services file system. The only prerequisite is to shut down the system in a normal way by using NetView. For more information on how to use this utility, see the details in the FEU.XXXX.PROCLIB(JCACHER).
The JACHER REXX program is stored in the FEU.XXX.SYSEXEC(JCACHER). JCACHER is a utility that can be structured. You can easily add new subsystems that need to be managed by using the required Java cache options. For ADCD, all the Java cache structures are written to subdirectories of /javasc in the UNIX System Services. To ensure that JACHER can work properly, the subdirectories and cache names need to have specific values. The subdirectory needs to be named after the started task name or PROC name. The name of the cache needs to be a concatenation of the started task name with the string cache. These parameters are defined by using the Java option Xshareclasses.
For example, z/OS Explorer is the subsystem of z/OS, and the task of z/OS subsystem on ADCD is RSED. Therefore, to define a cache for z/OS Explorer, you need to use the following Java option.
“-Xshareclasses:cacheDir=/javasc/rsed,name=rsedcache
Therefore, to add a z/OS subsystem that can be managed by JACHER, you just need to create a new subdirectory under /javasc, and set the owner of the directory and permissions to ensure that the new subsystem can write to the subdirectory. Typically, the owner of the directory is the user ID that is assigned to run started task by the RACF® STARTED class. Then, set up the new subsystem to use the -Xshareclasses parameters.

Other considerations

To speed up the startup of a z/OS system, you can select not to activate or start the subsystems that consume significant resources during initial IPL process if you do not use the subsystems. Take the following z/OS subsystems as examples.

  • z/OSMF for the task IZUSVR1
  • z/OS Explorer for the task RSED and JMON
  • UrbanCode for the task BUZAGNT
  • z/OS Connect for the task ZOSCSRV
  • Dependency Based Build Daemons (DBB and DBBS)
  • Debug for the tasks EQAPROF and EQARMTD

For more information on how to enable or disable the specific task startup during IPL process, see Adding tasks to NetView automation.