1 Performance Optimization in Java/J2EE

Transcription

1 1 Performance Optimization in Java/J2EE 1.1 Java Server Technology (J2EE) Fundamentals Overview To reduce costs and fast-track enterprise application design and development, the Java 2 Platform, Enterprise Edition (J2EE ) technology provides a component-based approach to the design, development, assembly, and deployment of enterprise applications. The J2EE platform offers a multi-tiered distributed application model, the ability to reuse components, integrated Extensible Markup Language (XML)-based data interchange, a unified security model, and flexible transaction control. The J2EE platform specifies technologies to support multi-tier enterprise applications. These technologies fall into three categories: component, service, and communication. The component technologies are those used by developers to create the essential parts of the enterprise application, namely the user interface and the business logic. The component technologies allow the development of modules that can be reused by multiple enterprise applications. The component technologies are supported by J2EE platform's system-level services. These system-level services simplify application programming and allow components to be customized to use resources available in the environment in which they are deployed Component Technologies A component is an application-level software unit. In addition to JavaBeans components, which are part of the J2SE platform, the J2EE platform supports the following types of components: applets, application clients, Enterprise JavaBeans (EJB )components, Web components, and resource adapter components. Applets and application clients run on a client platform, while EJB, Web, and resource adapter components run on a server platform Containers All J2EE components depend on the runtime support of a system-level entity called a container. Containers provide components with services such as lifecycle management, security, deployment, and threading. Because containers manage these services, many component behaviors can be declaratively customized when the component is deployed in the container. For example, an application component provider can specify an abstract name for a database that an Enterprise JavaBeans component needs to access, and a deployer will link that name with the information (such as a user name and password) needed to access the database in a given environment. 1

2 Web Component Containers Web components are hosted by servlet containers, JSP containers, and Web containers. In addition to standard container services, a servlet container provides the network services by which requests and responses are sent. It also decodes requests and formats responses. All servlet containers must support HTTP as a protocol for requests and responses; they may also support other request-response protocols such as HTTPS. A JSP container provides the same services as a servlet container. Servlet and JSP containers are collectively referred to as Web containers EJB Component Containers Enterprise beans are hosted by an EJB container. In addition to standard container services, an EJB container provides a range of transaction and persistence services and access to the J2EE service and communication APIs. 1.2 Garbage Collection Overview In computer science, garbage collection (GC) is a form of automatic memory management. The garbage collector, or just collector, attempts to reclaim garbage, or memory used by objects that will never be accessed again by the application. 2

3 Before the garbage collection is explained, it is necessary to we understand the how an object typically goes through most of the following states between the time it is allocated and the time its resources are finally returned to the system for reuse. Created In use (strongly reachable) Invisible Unreachable Collected Finalized De-allocated The basic principle of how a garbage collector works is: Determine what data objects in a program will not be accessed in the future Reclaim the resources used by those objects GC Benefits Garbage collection frees the programmer from manually dealing with memory allocation and de-allocation. As a result, certain categories of bugs are eliminated or substantially reduced: Dangling pointer bugs, which occur when a piece of memory is freed while there are still pointers to it, and one of those pointers is used. Double free bugs, which occur when the program attempts to free a region of memory that is already free Types of Garbage Collection Mark-Sweep-Compact GC is then done in three phases: mark, sweep, and optionally compaction. We call this a stop-the-world (STW) collection, because all application threads are stopped while garbage is collected. IBM JVM implementation adapts this algorithm for the garbage collection Generational A generational GC divides objects into generations and, on most cycles, will place only the objects of a subset of generations into the initial set. Furthermore, the runtime system maintains knowledge of when references cross generations by observing the creation and overwriting of references. When the garbage collector runs, it may be able to use this knowledge to prove that some objects in the initial white set are unreachable without having to traverse the entire reference tree. SUN Hotspot Java adapts this algorithm for the garbage collection 1.3 How to resolve Memory issues 3

4 The cost of memory leaks is significant and is often associated directly with production down time, or a slipped deployment schedule. Unfortunately, the costs of appropriate test solutions are also significant, and customers are often unwilling -- or unable -- to invest the resources necessary There are four common categories of memory usage problems in Java: Java heap memory leaks Heap fragmentation Insufficient memory resources Native memory leaks Reason for Memory Leaks In general, a Java heap memory leak results when an application unintentionally (due to program logic error) holds on to references to objects that are no longer required. These unintentional object references prevent the built-in Java garbage collection mechanism from freeing the memory used by these objects. Common causes for these memory leaks are: Insertion without deletion into collections Unbounded caches Un-invoked listener methods Infinite loops Too many session objects Poorly written custom data structures Complexity of finding Memory Leak There are a number of problems that cause memory leaks to be particularly troublesome for System Administrators in the production environment: Traditional Java memory leak root cause detection techniques have significant performance burdens and may not be suited for use in production environments. These techniques usually include heap dump analysis, attaching JVMPI (Java Virtual Machine Profiler Interface) or JVMTI (Java Virtual Machine Tools Interface) agents, or the use of byte code insertion to track insertions and deletions into collections. Traditional redundancy methods such as clustering can only help to a certain extent. Memory Leaks will propagate throughout cluster members. An affected application server's response rate slows workload management techniques. This can cause requests to be routed to healthier servers and result in coordinated application server crashes Wrong ways of handling the memory Leaks The following are the ad-hoc way of overcoming the Memory Leaks in the production though it is not helping solve the memory problems as they are concluded as wrong ways of mitigating the memory leak issues: Increasing the Upper limit of Heap Size Increasing the JVM server process in the cluster. Auto restart of JVM process frequently 4

5 1.3.2 Resolving Memory Leaks in IBM JVM Step 1 Collection of Heap Dump Once a memory leak has been detected and heap dumps have been generated, they can be transferred outside the production server and into a problem determination machine for analysis. Note: IBM Java supports the automated Heap Dump generation Step 2 Analyzing the Heap Dump Memory Dump Diagnostic for Java (MDD4J) is an offline heap dump analysis tool that aids in the process of determining the root cause of the memory leak. The analysis mechanism identifies suspected leaking data structure classes and packages. This identification enables the Performance Engineer to narrow down the root cause of the memory leak to a few component applications Step 3 Profiling the affected application transactions Once the memory leak related components are identified, then Developer can do set up the Dynamic profiling environment set up using JProfiler or JProbe to analyze the affected application transactions with those components. Profiling memory snap shot will help to pinpoint the faulty source code shorter time. Some time Developer can be able to find by manually to find the faulty source code Resolving Memory Leaks in SUN JVM Step 1 Collection of Heap Dump Option 1 Command line Option By setting the parameter -XX:+HeapDumpOnOutOfMemoryError option, Heap dump will be generated when JVM detects the out-of-memory error Option 1 HPROF Profiler The HPROF profiler agent can create a heap dump while the application is executing. The following is an example of the command line: $ java -agentlib:hprof=file=snapshot.hprof,format=b application If the VM is embedded or is not started using a command line launcher that allows additional options to be provided, then it might be possible to use the JAVA_TOOLS_OPTIONS environment variable so that the -agentlib option is 5

6 automatically added to the command line. See A.2 JAVA_TOOL_OPTIONS Environment Variable for further information on this environment variable. Once the application is running with HPROF, a heap dump is created by pressing Ctrl- \ or Ctrl-Break or kill -3 <pid> (depending on the platform) on the application console. When the signal is received, a heap dump is created; in the above example the file snapshot.hprof is created Option 1 jmap Utility A heap dump can also be obtained using the jmap utility. The following is an example of the command line: $ jmap -dump:format=b,file=snapshot.jmap process-pid Regardless of how the Java VM was started, the jmap tool will produce a head dump snapshot, in the above example in a file called snapshot.jmap. The jmap output files should contain all the primitive data, but will not include any stack traces showing where the objects have been created Option 1 JConsole Utility Another way to obtain a heap dump is with the JConsole utility. In the MBeans tab, select the HotSpotDiagnostic MBean, then the Operations display, and choose the dumpheap operation Step 2 Analyzing the Heap Dump The heap dump will be analyzed using the tool called jhat (Java Heap Analysis Tool). The jhat command parses a java heap dump file and launches a webserver. jhat enables you to browse heap dumps using your favorite webbrowser. jhat supports pre-designed queries (such as 'show all instances of a known class "Foo"') as well as OQL (Object Query Language) - a SQL-like query language to query heap dumps. Help on OQL is available from the OQL help page shown by jhat. With the default port, OQL help is available at Step 3 Profiling the affected application transactions Once the memory leak related components are identified, then Developer can do set up the Dynamic profiling environment set up using JProfiler or JProbe to analyze the affected application transactions with those components. Profiling memory snap shot will help to pinpoint the faulty source code shorter time. Some time Developer can be able to find by manually to find the faulty source code 6

7 1.4 How to resolve Thread Lock issues Many of today's Java applications take advantage of the language's ability to support concurrent programming through the use of threads. Multiple threads can potentially share the same data objects, but if the part of your application that controls these threads is designed poorly, you may experience lock contention and correspondingly poorer performance. In multithreaded applications, for example, if multiple threads access the same resource for reading and writing, thread synchronization problems can occur. If one thread attempts to read from a file whilst another is writing to it, the data may become corrupted. To resolve this problem, the Java language allows a thread to acquire an exclusive lock on objects, preventing any other thread accessing it. Once the thread has finished with the object, it releases it so that other threads can then gain access. However, this mechanism can cause high levels of contention if applications aren't designed with care. Lock contention occurs when a lock is currently in use and another thread attempts to acquire it by another thread. High levels of contention can occur on locks that are frequently obtained, held for a long time, or both. A highly contended lock (one in which many threads try to gain access) can become a bottleneck in the system, as each running thread will pause its execution until the lock it requires becomes available, limiting application performance Resolving Thread Locks in IBM JVM IBM Thread and Monitor Dump Analyzer for Java Technology IBM Thread and Monitor Dump Analyzer for Java Technology analyzes javacore and diagnoses monitor locks and thread activities in order to identify the root cause of hangs, deadlocks, and resource contention or monitor bottlenecks. This technology analyzes each thread information and provides diagnostic information, such as current thread information, the signal that caused the javacore, Java heap information (maximum Java heap size, initial Java heap size, garbage collector counter, allocation failure counter, free Java heap size, and allocated Java heap size), number of runnable threads, total number of threads, number of monitors locked, and deadlock information IBM Thread and Monitor Dump Analyzer for Java Technology compares each javacore and provides process ID information for threads, time stamp of the first javacore, time stamp of the last javacore, number of garbage collections per minute, number of allocation failures per minute, time between the first javacore and the last javacore, number of hang suspects, and list of hang suspects. IBM Thread and Monitor Dump Analyzer for Java Technology also compares all monitor information in javacore and detects deadlock and resource contention or monitor bottlenecks, if there are any IBM Lock Analyzer for Java The IBM Lock Analyzer for Java (JLA), a new tool available from alphaworks that runs on any platform running an IBM-supplied Java SDK or JRE, version 5.0 or above, performs lock 7

8 analysis on a live application to highlight thread activity and provides insight into how often locks are contended. This view can help with the resolution of lock contention problems and performance issues. The JLA runs alongside an existing Java application and gathers all of that application's lock information. Each lock is recorded along with details about it, such as how long it is held, whether it contends, and the percentage of the time it blocks threads trying to obtain it. The tool consists of a runtime library that must be loaded at startup with the application you wish to monitor and a front-end graphical user interface that displays the results and performs analysis Resolving Thread Locks in SUN JVM Collecting Thread Dump in Command Prompt The Thread dump from SUN JVM can be obtained by following techniques Ctrl-Break in Windows If Application console is available Kill -3 <pid> in the UNIX/Linux platform Collecting Thread Dump using jstack If the process is running as back ground process or JVM output is directed to an unknown location, then the jstack utility can be used to obtain the stack thread by calling jstack -<pid> Thread dump can be obtained from the core dump by using the command $ jstack $JAVA_HOME/bin/java core 1.5 Clustering Vs. Load Balancing Need of High Availability Enterprise web portal applications must provide scalability and high availability (HA) for web services in order to serve thousands of users hitting a mission-critical server application site. Scalability is the system's ability to support increasing numbers of users by adding additional servers to the cluster. High availability is basically providing redundancy in the system. If a cluster member fails for some reason, another member in the cluster can transparently take over the web requests. Deploying a web portal application in a cluster environment gives us the ability to achieve scalability, reliability, and high availability required by the web portal application. Basically, the main goal of clustering is to prevent any web site outage problems occurring due to a Single Point of Failure (SPoF) in the system. Large-scale system design provides mission-critical services to ensure minimal downtime and maximum scalability in an enterprise application environment. Rather than run a single server, multiple cooperating servers are run. To scale, you should include additional machines within the cluster and to minimize downtime, you should make sure every component of the cluster is redundant. The main ingredient of a large-scale system is clustering, which includes load balancing, fault tolerance, and session state persistence features. 8

9 Usually for web applications, a hardware- or software-based load balancer sits in front of the application servers within the cluster. These load balancers are used to distribute the load between the cluster nodes by redirecting web traffic to an appropriate cluster member, at the same time detecting any server failures. For the any mission-critical enterprise application, Clustering and Load balancing should be combined together to achieve the High Availability and Scalability Clustering A cluster is defined as a group of application servers that transparently run a J2EE application as if it were a single entity. There are two methods of clustering: vertical scaling and horizontal scaling Vertical scaling Vertical scaling is achieved by increasing the number of servers running on a single machine, whereas horizontal scaling is done by increasing the number of machines in the cluster. With vertical scaling, the machine's processing power, CPU usage, and JVM heap memory configurations are the main factors in deciding how many server instances should be run on one machine (also known as the server-to-cpu ratio) Horizontal scaling Horizontal scaling is more reliable than vertical scaling, since there are multiple machines involved in the cluster environment, as compared to only one machine. Load Balancing Fault Tolerance There are two levels of fail over capabilities typically provided by clustering solutions: Request-level fail over If one of the servers in the cluster goes down, all subsequent requests should be redirected to the remaining servers in the cluster. This involves using a heartbeat mechanism to keep track of the server status and to avoid sending requests to the servers that are not responding. In our cluster setup, a Tomcat instance acting as a load balancer takes care of request level fail over by forwarding web requests to another node in the cluster Session-level fail over A web client can have a session that is maintained by the HTTP server. In session-level fail over, if one of the servers in the cluster goes down, another server in the cluster should be able to carry on with the sessions that were being handled by the first server, with minimal loss of continuity. This involves replicating the session data across the cluster. A Tomcat cluster with session replication capability takes care of session-level fail over. 9

10 1.5.3 Load Balancing Load balancing (also known as high availability switch over) is a mechanism where the server load is distributed to different nodes within the server cluster, based on a load balancing policy. Rather than execute an application on a single server, the system executes application code on a dynamically selected server. When a client requests a service, one (or more) of the cooperating servers is chosen to execute the request. Load balancers act as single points of entry into the cluster and as traffic directors to individual web or application servers. There are many different algorithms to define the load distribution policy, ranging from a simple round robin algorithm to more sophisticated algorithms used to perform the load balancing. Some of the commonly used algorithms are: Round-robin Random Weight-based Minimum load Last access time Programmatic parameter-based (where the load balancer can choose a server based upon method input arguments) 1.6 Best Practices to achieve the performance in J2EE applications Code Optimization Techniques Use of StringBuffer while string concatenation Use StringBuffer instead of String Operator + when a large amount of string concatenation is being done to avoid the creation of many small, temporary objects Caching the JNDI InitialContext and EJB Home interfaces For increased performance in applications that use a large number of Entity Beans, consider caching the JNDI InitialContext and EJB Home interfaces. This optimization should be encapsulated within the EJB business object factory so there is no effect on business object client code Avoid Stateful session bean Be sure to remove instances of stateful container overhead and processing Choose right XML Parser If you use XML extensively throughout your application and performance is a concern, choose the most efficient parsing method available to you that meet your requirements. DOM parsers are usually the slowest due to the large number of objects instantiated underneath the covers and their generic nature. If your application simply needs to parse through a document once and deal with the data right away, the SAX parser is much more efficient. 10

11 Binding frameworks such as JAXB will also be more efficient because they know exactly what they are looking for in the XML or what XML tags they need to create Choose Asynchronous processing as an alternative Consider the use of asynchronous processing to alleviate performance concerns in applications with semi-real-time updates, multiple external applications that can be invoked in parallel, or work that can be partitioned into segments. Use Message-Driven Beans and JMS to implement parallel processing in a J2EE container. Asynchronous processing can also be used to increase the perceived performance of an application Tuning configuration Once the proper Performance Engineering engagement is carried out to fix performance bottlenecks within the application, tuning activities should be explored to attain the maximum performance from the J2EE application server. Commonly tuning can be done in the following areas of J2EE resources counters: JVM Heap o Heap Limit Settings o Garbage Collection Strategies Default Throughput Collector Adaptive Concurrent Sweeping Worker or Execute Thread o Pool size o Thread Pool Queue length EJB o Pool Size o Cache Size o Refresh Cache Time DB Connection o Pool Size o Connection Timeout o Statement Execution Timeout 1.7 Profiling & Monitoring Tools Profiling Tools The Profiling tools can mainly used in the development / test environment where to find the costly method invocation or finding root cause of the memory leaks. There are lots of commercially and open source tools available. The following are the some of the popular tools: JProfiler JProbe etc 11

12 The profiling activity serves the two main purposes that in the following: CPU Profiling This type of profiling is to find the CPU bottlenecks on the critical transactions due to the following possible reasons: Too many invocation of particular function(s) in the looping Narrowing the Costly methods that contributes maximum % of execution Memory Profiling This type of profiling is to find the memory on the critical transactions due to the following possible reasons: Too many creation of objects that are not used Narrowing the root cause of memory leaks by verifying counts of relevant set of variables that are associated with application transaction with explicit GC operation Monitoring Tools In the Java Server Technology ( J2EE), there are lots of monitoring tools that are available to monitor the J2EE server in production and test environment. Though the most of monitoring tools are fascinating to deploy and monitor in the production, they still consumes CPU and Memory foot prints. So System Administrator should have better H/W configuration to support those tools in the production servers. The J2EE monitoring tool internally uses the JMX Services to monitor the J2EE resource counters: JVM Heap Worker Thread pool Usage DB Connection Pools usage HTTP Session Count EJB Pool usage etc J2EE Resource Counters The following are the typical J2EE counters: Thread Pool Size DB Connection Pool IBM WAS Performance Monitoring Infrastructure It is formerly called as Tivoli Performance Viewer (TPV) and now it is fully integrated with IBM Web Sphere Application Server. 12

13 Custom BEA Web Logic Monitoring tool using MBean API Weblogic provides the MBean API that can be used to develop the custom Web Logic Monitoring tool CA-Wily Introscope Monitoring tool This tool is to monitor the popular J2EE application servers like IBM Websphere, Bea Weblogic application servers. This can be used in the production environment SUN JConsole for J2SE JConsole is used only to monitor the J2SE application. It does not monitor any J2EE application server Reference Designing Enterprise Applications with the J2EE Platform, Second Edition by Inderjeet Singh; Beth Stearns; Mark Johnson; the Enterprise Team Publisher: Prentice Hall Pub Date: March 25, 2002 Print ISBN-10: Print ISBN-13: Pages: 448 IBM Java Garbage Collection: SUN HotSpot Java Gargbage Collection Wikipedia How to resolve memory issue IBM Java dar.html How to resolve memory issue SUN Java How to resolve Thread lock in IBM Java 13

14 How to resolve Thread lock in SUN Java Clustering Vs.Loadbalancing Thread Lock IBM Java Thread Lock avoiding Monitoring JConsole 14