Last week I talked about three important Java DB2 performance best practices that can help prevent performance problems before they get into production. Unfortunately, the comments from readers indicated that the Java DB2 performance problems are already in production and the database is being blamed. Proving the database is not the issues always requires performance documentation. While you are proving it is not DB2, ask the production application developers or analyze these three items to improve Java performance.
First, ask for and document the number of remote calls the web or Java application is performing. Since the Java DB2 performance problems are in your production environment, analyze each of the many outside calls to remote servers or even to other applications within your company. With each one of the remote calls Java performance is degraded through the latency of security, serialization, network throughput and memory management. Some customer facing e-commerce sites have an extraordinary number of remote servers; sometimes more than 20 remote calls are performed before the web paged is displayed. Document, minimize and eliminate as many remote calls as possible to improve Java DB2 performance. Also document the remaining remote calls that are absolutely necessary for the application to function.
Next, optimize the application memory usage and its scalability to get a dramatic Java DB2 performance improvement. All applications allocate and de-allocate memory through the normal processing of their transactions. The amount of memory used and then discarded for garbage collection can have a big negative impact within poorly designed or architected applications. Document the memory footprint of the application transactions, the memory required for processing the data and how much memory is discarded. Some of the systems and applications that I have analyzed during Java DB2 performance reviews show that the application discards too much memory, causing the server to waste CPU on garbage collection processing. Over-allocating memory within an application can stress the server or virtual machine operating system through extended system paging. Document the memory usage within your applications, understand the CPU wasted through garbage collection and optimize your memory usage to improve your Java DB2 performance.
Third, minimize all the components used within your application architecture. Performance improvement is achieved by only doing what is absolutely necessary within a transaction. Extra activities that do not contribute or enhance the transaction should be eliminated. Examining Java profiles of different performance reviews I have done for clients’ Java applications shows hundreds of service-oriented architecture modules called and sometimes thousands of database SQL statements being performed. Each call to a module or database requires serialization and synchronization and impacts your Java DB2 performance. These thousands of serializations and synchronizations can be very small but can add up to be time consuming within your overall application transaction. Sometimes you’ll also discover a huge amount of time spent within third party calls for credit card approvals, address checks or other external calls. So look at the number of components and understand where all the time is spent serializing or synchronizing because optimizing them can dramatically improve Java DB2 performance.
_________________________________________________________
The IDUG early bird discount ends on April 6. Sign up for IDUG today!
I look forward to speaking at the IDUG DB2 Tech Conference 2012 North America conference. The conference will be held in Denver, Colorado on May 14-18, 2012. Sign up today at www.idug.org.
Also, I am beginning to plan my Regional DB2 User Group support for the rest of 2012. Please send an email to me at moc.ekluebevadnull@evad if you would like me to come and speak or offer a DB2 class at your local user group.
Leave a Reply