Heap management in JAVA

Heap is the important concept for analyzing performance of Java application and to understand the details of Heap we need to understand how JVM uses the system memory. In JVM memory can be divided into following categories

• -          Heap memory
• -          Non Heap memory
• -          Other (JVM code, internal structure etc.)

The Java heap space is the run time data area from which the JVM allocates memory for all of the Java application's objects and arrays. So when we create any object in JAVA we are basically creating that object in the heap area. From the performance testing point of view Java heap space is the most frequently tuned feature of a JVM, and is configured with the -Xms -Xmx command line options. 

One of the important points to remember here is maximum heap size we can define for 32 bit OS is 4 GB while that for 64 GB is 32 GB.

Non Heap memory stores per class structures like runtime constant pool, field and method data, and the code for methods and constructors, as well as interned Strings.

Unfortunately, the only information JVM provides on non-heap memory is its overall size. No detailed information on non-heap memory content is available.

Coming back to Heap memory, we can consider Heap to be divided into two categories:

-          Eden and tenured.

Initially all objects gets created in Eden space. Once GC is called objects which are not required or referenced any more gets deleted and still referenced objects are move to survivor area with in Eden space and objects which survive the GC on survivor area are moved to tenured area. We have this division to have better memory management and performance.  As there are various objects with different life cycle – Some objects remain live throughout the application while some objects die very soon. That is the reason we system provide different categories inside heap. Performing a GC on tenured area is more expensive then the Eden area.

Sizing the heap memory is a critical decision which should be taken based on the application. If we sized the heap memory to be large then during GC application may become unresponsive as JVM would be busy in doing the GC on large amount of memory also if we specify Heap to be less, throughput could be impacted due to increases in call for GC and can lead to “Out of memory exceptions”

Dynamic parameterization

Problem is to get dynamic proxy name and details (username,password) based on the different load generator machine. These machines could be in different zones with having different proxy servers.

Following code helps in getting the proxy details based on the current machine. Same solution can be used when we have to pick the substitution from the parameter list based on any condition. One example could be a search term. Say for Example I have n number of search term some search terms are invalid. Our requirement could be if a search term is invalid run the search query for same user with different search term.




int i, result;
char *current_host;
current_host = lr_get_host_name();
lr_output_message("The Actual Host is %s", current_host);
//Run the loop based on the number hosts you have in the parameter list
for(i=0;i<=20;i++)
{
lr_output_message("Current Host being verified is %s", lr_eval_string("{Host_Name}"));


if(strcmp(current_host,lr_eval_string("{Host_Name}"))==0)
{
lr_output_message("Setting the Username (%s), Password (%s) & Domain Name (%s) related to Host Name (%s)", lr_eval_string("{User_Name}"),lr_eval_string("{Password}"), lr_eval_string("{Domain}"), lr_eval_string("{Host_Name}"));
web_set_user("{User_Name}", "{Password}", "{Domain}");
break;
}
else
{
lr_output_message("Current Host evaluated is (%s) not matching with actual host", lr_eval_string("{Host_Name}"));
lr_advance_param("Host_Name");
}

Replay Engine in LoadRunner

Loadrunner have support for Socket and Winlnet replay engines for replaying the script. We can control this setting from Replay>Run Time Settings.

In above screenshot we can see there is an option to change replay choice between Sockets and WinInet. By default Loadrunner use the socket options and we should also use Socket only unless we WinInet is the only choice.

Socket is a scalable approach which used Loadrunner proprietary interface to communicate with the network whereas WinInet uses WinInet API which is used by Internet Explorer to communicate with the network. WinInet helps in resolving issues with the playback but it is not recommended for running the load test as it comes with the limitation of scalability.

Switching to winInet option is a good step to troubleshoot the replay errors.