A Study Paper on Performance Degradation due to Excessive

Applications are becoming more complex, more larger and demand high quality. Application Server is the component on which most of the applications are hosted. It acts in the middle tier providing lot of functionalities like transaction management, caching ,persistence clustering etc. There are a variety of application servers to choose from like JBoss, Websphere, Tomcat etc, some are open source while others are proprietary. Quality parameters like performance, availability, scalability, maintainability, re-usability vary between different application servers. The application servers can be analyzed and monitored for performance using various tools and metrics. The quality parameters of an application server are affected by various factors such as memory leak, poor performing code, etc. It is necessary to evaluate the performance, to verify if the quality requirements are met. Software Engineering has several methodologies, metrics and calculations to evaluate the quality requirements. [1] discusses the various measurements and metrics that can be used to calculate the quality parameters.

Lot of factors affects the performance of a Java application. Factors that directly affect the performance of a Java application are heap size, threads and connection pooling. If more heap size is allocated then more java objects can be stored in the heap space. So the garbage collection can take place sparingly or the application can utilize more CPU cycles on performing the functionality rather than garbage collecting. But when garbage collection takes place, more objects needs to be searched for collecting the garbage object. On the other hand if less heap space is allocated the application does garbage collection very often. In this paper we discuss on the memory usage monitoring and garbage collection in Java based applications. Excessive garbage collection affects the performance of a Java based application though there are tunable parameters in JVM to perform garbage collection. The tool used for memory usage analysis is the Netbeans IDE profiler. The result shows that for high scaling applications improper garbage collection and memory leak can be a serious bottleneck that needs to be addressed. This project is a motivation of a research work on performance study in Java based applications. This paper proposes an analysis on memory that may cause poor performance in an application. Problems like memory leak slow down the processing of jobs [2]. The memory leak needs to be identified at the early stage of deployment and remedial actions taken to fine tune the code so as to avoid memory leaks.

Experiments -Identifying Memory Leaks
There are several tools to analyze memory and monitor memory usage. The Netbeans IDE profiler is one among them that records the behavioral aspects of the application. The profiler is a tool that has been inbuilt with the latest version of Netbeans IDE. It helps in analyzing the memory, the heap size etc. The process involved in performing the profiling is out of the scope of this paper.
These experiments were conducted in uniprocessor system. The Java platform used was jdk1.6 in Windows operating environment.
Several case studies were performed and access the memory utilization and how they affect the overall performance of an application server. The results are discussed below.

Case Study 1 and Evaluation Results
The NetBaeans profiler was used to evaluate some of the Java applications developed. The Java application developed was deployed in NetBeans IDE and the JBOSS Application Server was started. Inorder to run the NetBeands profiler the following steps were followed; 1. Run the profiler calibration. Calibration is done on the JDK running on the machine.This is a one time action. 2. Integrate the profiler with the project 3. Analyze the results of memory profiling The entire application can be profiled or parts of application alone can be profiled. Further there is option of profiling all Java classes or only project classes. There is option of filtering out Java core classes alone. User defined profiling points alone can also be taken up for analysis.
The experiment was conducted to profile the entire application as well as only core java classes of the application. that has not been garbage collected over time. As the object survives different garbage collections that occur, the age of the object increases. The age of the object is the number of garbage collection that the object has survived(centre graph)..  The purple shade indicates the percentage of execution time spent by JVM doing garbage collection (centre graph). This percentage of execution time the JVM does not execute the application. If this percentage is more then the garbage collection parameters needs to be tuned in JVM.  Count of generation = age of object1 + age of object 2 +….+age of object n

Results
In the experiment:  The allocated JVM heap size is above 300 megabytes (left graph).  The JVM heap size actually in use varies from above 100 megabytes to 200 megabytes (left graph).
There is a provisioning to run the garbage collection forcibly. When the garbage collection was forcibly done, the results obtained are as shown in the below figure: The basic telemetry information of the project as given by the tool is as given below:

Fig 3: Basic telemetry informationentire application
While the experiment is being conducted if there is a need to convert profiling to only project classes that can also be done. This need may arise due to the factors that too much data collected and the profiler ran out of memory. OutOfMemoryError may occur due to several reasons including HttpUnit doesn't support Java Script processing.  Inference: When the GC is forcibly run the used memory is getting reduced. Reducing garbage collection times increase the performance. Garbage collection (GC) delays can be successfully lowered to by using parallel garbage collection algorithms. But most of the application do have modules which executes sequentially and does not do parallel processing.
Even if the JVM spends 1% of time in garbage collection in a uniprocessor system, it translates to more than a 20% loss in throughput on 32 processor systems [3]. Hence this is a major problem that needs to be addressed. Improvements in garbage collection process or avoiding memory leaks to a smaller extend can show better performance results. Garbage collection may become a principle bottleneck for large scale applications.