Author: Ajay Srivastava FEB 2004

4
Best Practices for JAVA, AS/400 Websphere Development Page 1 of 4 Author: Ajay Srivastava FEB 2004 Background Performance is a critical component of customer satisfaction. As an application is design and constructed, the software architects should be aware of performance- critical areas. Likewise, after an application is deployed, the environment should be tuned to ensure the best possible performance. This paper will provide tips and best practices, which should be followed during development, deployment and during post deployment of any n-tier JAVA application on IBM Websphere and AS400 (now iSeries) platform. Intended Audience The paper is intended for anyone responsible for the development and deployment of high performance and scalable AS400/JAVA applications, including application architects and developers. The readers of this paper are assumed to have good knowledge of IBM AS400, Websphere, Java and Java-related technologies. Best Practices during Development Design Principles and Best Coding Practices In relation to coding standards and best optimization techniques (for example connection pooling, using HTTP sessions etc), certain guidelines should be followed. A useful document for reference is a document called “Websphere Application Server Development Best Practices for Performance and Scalability”, which can be found at following URL: http://www-1.ibm.com/support/docview.wss?uid=swg27000615 The JDBC Performance Tips (targeted at AS/400, but generically applicable) can be found at following URL: http://www- 919.ibm.com/servers/eserver/iseries/developer/java/topics/jdbctips.html

Transcript of Author: Ajay Srivastava FEB 2004

Page 1: Author: Ajay Srivastava FEB 2004

Best Practices for JAVA, AS/400 Websphere Development

Page 1 of 4

Author: Ajay Srivastava FEB 2004

Background Performance is a critical component of customer satisfaction. As an application is design and constructed, the software architects should be aware of performance-critical areas. Likewise, after an application is deployed, the environment should be tuned to ensure the best possible performance. This paper will provide tips and best practices, which should be followed during development, deployment and during post deployment of any n-tier JAVA application on IBM Websphere and AS400 (now iSeries) platform.

Intended Audience The paper is intended for anyone responsible for the development and deployment of high performance and scalable AS400/JAVA applications, including application architects and developers. The readers of this paper are assumed to have good knowledge of IBM AS400, Websphere, Java and Java-related technologies.

Best Practices during Development Design Principles and Best Coding Practices In relation to coding standards and best optimization techniques (for example connection pooling, using HTTP sessions etc), certain guidelines should be followed. A useful document for reference is a document called “Websphere Application Server Development Best Practices for Performance and Scalability”, which can be found at following URL: http://www-1.ibm.com/support/docview.wss?uid=swg27000615 The JDBC Performance Tips (targeted at AS/400, but generically applicable) can be found at following URL: http://www-919.ibm.com/servers/eserver/iseries/developer/java/topics/jdbctips.html

Page 2: Author: Ajay Srivastava FEB 2004

Best Practices for JAVA, AS/400 Websphere Development

Page 2 of 4

Database Drivers The AS400 native JDBC driver is the part of AS400 JVM, and performs much better than the IBM toolbox JDBC driver. The toolbox driver runs on any JVM while native JDBC driver runs only on AS400 JVM. The best practice is to avoid any hard-coding in the program to use a specific JDBC driver. Instead, JDBC driver should be configurable at runtime. AS400 Native Compilation Instead of 32-bit class file, the external application source files should be compiled on AS400 native environment using native JDBC driver, which will improve the performance, by a factor of ten (according to IBM). This improvement will only be valid for classes loaded via AS400, and not the Websphere classloader. The application source files can be compiled using “JAVAC” utility available on AS400 JVM. JVM Optimization on AS400 It should be avoided using “RUNJVA” command to access remote objects. The command tries to restart JVM and has a large impact on the machine, as it generally takes few seconds to approximately one minute to start the JVM. Instead of this, the remote access of objects should be via RMI/IIOP. Application Logging Immense amount of logging should be avoided. Application logging must be configurable (either YES or NO) at run time- only critical error message should be logged in the production system. It is always better to use a third-party logger such as “Jakarta Apache project’s log4j”- the use of this can be as easy as changing a configuration parameter.

Best Practices during Deployment/Post Deployment Operating System Configuration Memory Pool Applications and related subsystems should be run in a separate memory pool. It is required to make a clear distinction between the applications and system jobs on AS400. A separate memory pool should be created for each applic ation and related subsystems. A dedicated amount of memory should be allocated to the pool to measure application performance more clearly. Data Base Main Files Access Paths The system should be analyzed to prepare the list of the main database files, which are growing in nature and are more frequently, accessed via application. In order to improve record access time for these files, the access path should be brought into memory using (“SETOBJACC”) command.

Page 3: Author: Ajay Srivastava FEB 2004

Best Practices for JAVA, AS/400 Websphere Development

Page 3 of 4

Disk I/O By using performance monitor tools or the Work with Disk Status (WRKDSKSTS) command, it is possible to detect long persistent periods of highly uneven DASD utilization. If something could be done to spread the DASD utilization more evenly, overall system performance could be enhanced. The commands “TRCASPBAL” and “STRASPBAL” should be run on regular basis, as it will improve disk performance. The Trace ASP Balance (TRCASPBAL) command is used to collect information that can later be used to balance the data so as to improve the DASD utilization. The trace maintains a table that divides the DASD units into stripes and maintains an I/O count for each stripe. It also maintains a utilization level for each DASD unit during this trace period. This allows for the identification of hot (high use) stripes and cold (low use) stripes. Furthermore, it identifies units that have high use. Once a trace has been collected, another command, Start ASP Balance (STRASPBAL), can be used to start the analysis and data balancing. Dump JVM The Dump JVM (DMPJVM) command can be used to learn about garbage collector performance, which provides a spool file with information about JVM, including some of the key garbage collector data -- initial heap size, maximum heap size, current heap size and number of collections since the JVM was started. It also includes a dump of the objects currently in the heap, which can be helpful for analyzing object leak problems. (Object leaks occur when application creates new objects and keeps a reference to the objects even when they're no longer needed, preventing the collector from collecting them.)

Tune System for faster connect times Applications may results in poor performance that attempt to establish a relatively large number of connections in a short period of time. This is especially true if the AS/400 system has not been tuned for performance. Java database accesses using the native JDBC driver require a pre-started job (PSJ), also known as a server job -- QSQSRVR -- to process the statements. The default system settings for this job work fine for many environments, but for frequent connect/disconnect workloads the settings should be changed. The defaults are 5 initial jobs started, a threshold (minimum number of server jobs available) of 2, and 2 additional jobs added for each threshold exceeded. WebSphere Application Server Configuration Application Server Log Files Application server standard log and output files should be deleted periodically to free the disk space. These files can be deleted from the system as they are automatically created when the Websphere Application Server instance restarts. Application Server Heap Size The recommended Java heap size is 64 MB but it should be reviewed periodically with the application load.

Page 4: Author: Ajay Srivastava FEB 2004

Best Practices for JAVA, AS/400 Websphere Development

Page 4 of 4

Relax Auto Reloads Auto-reload facility impacts the server performance, as application server polls the application after every reload interval. An important rule of Server’s better performance is to turn off, or greatly relax, all dynamic reload parameters. For example, When an application's resources such as servlets and enterprise beans are fully deployed, it is not necessary to aggressively reload these resources as one would during application development. Deploy JAR/WAR file All application components should be deployed in either JAR or WAR or EAR files. This will give a very fine control over deployments, and will also ensure the partial-deployments never occur. Web Server Admin Instance It is not required to keep web server Admin instance always active. In order to save system memory and processing time, the admin instance of web server should only be started when needed. Application Server Start/Stop In order to start the application server properly, the application server should be stopped from the console, or at least in a controlled manner. This should be done using a WSCP (a useful tool to start and stop websphere objects) script, or by using a XMLConfig fragment to stop the node. Conclusion This paper provided a list of best practices that help improve the success of an application development and deployment on AS400 Websphere, DB2 and Java technologies. By following these practices, there is a better chance of developing a best product successfully.