Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Determine Your Java Software's Performance Capacity During Development : Page 2

Learn how to analyze load test data and calculate the performance capacity of your enterprise Java applications during development.


WEBINAR: On-demand Event

Unleash Your DevOps Strategy by Synchronizing Application and Database Changes REGISTER >

Comment Out All System.out

System.out statements put enormous load directly on the JVM, as well as indirectly on the underlying operating system. Too many System outs increase CPU utilization exponentially. So comment out all the System printout statements prior to running load tests (as you will see later, capacity planning involves CPU utilization values). For example, the following sample code takes 30 seconds to run using 80 percent of CPU capacity:

for(int i = 0; i < 900000; i++){ System.out.println("Doing cumulative math.."+i); sum = sum+i; System.out.println("Doing cumulative math interm sum .."+sum); }

However, the same code without the print statements takes only 9 milliseconds with less than 10 percent of CPU utilization:

for(int i = 0; i < 900000; i++){ sum = sum+i; }

Click to enlarge 
Figure 1. Load Averages Using Uptime

Data to Collect During Load Test

If you use *inx environments for your application server deployments, collecting the load on the OS is very important. All *inx systems use the /proc file system to provide an easy way to view kernel information and information about currently running processes. The Proc pseudo file system is a real-time, memory-resident file system that tracks the processes running on the machine and the state of the system. Process-specific information is stored within /proc under the process ID directory.

For load tests, pick the most time-consuming or computation-intensive API of your enterprise application or one iteration of all user activities on the system. Start the load test with 100 concurrent users and run it for at least 20 minutes. While the load test is running, use the uptime command to periodically record the load averages on the OS. Uptime gives the load on the system during the previous 1-, 5-, and 15-minute intervals. Load average specifies the number of processes waiting to compete for the CPU. Figure 1 gives the sample output of an uptime command.

You do not want too many processes waiting in line for the CPU, but at the same time you do not want too few processes in the system. The optimum load will have values hovering between 2 and 3. The 'top' command in the Figure 2 sample output shows CPU utilization and a memory snapshot of the system.

Click to enlarge 
Figure 2. CPU and Memory Snapshot Using Top

As you proceed with load tests, keep gradually increasing the number of concurrent users, paying attention to the CPU utilization, memory stats, and load averages until the load averages reach the optimum values (between 2 and 3).

In J2EE applications, the max-http-connections configuration controls the maximum allowable HTTP connections. Though the theoretical value is infinite, after a certain number the response time will gradually increase for each request to the server. At this juncture, it is better to have another instance of the server. Usually the documentation of the application server provides these values for optimum performance. Multiple J2EE instances can be installed on the same server with different port numbers. A load balancer is needed if multiple instances of the application are used.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date