• Beware of “Thread.run()” versus the real intend of “Thread.start()” – We may unknowingly code the thread as “run()”.  This will cause the thread to run sequentially instead of concurrently. Beware of this!  Use “Thread.start()” to allow the thread to run concurrently.
• Use “String.length ()  == 0” instead of “String.equals(“”)” – Both constructs do the same thing of comparing if any characters exists for the string. However, the first construct, “String.length() == 0” is more efficient than the latter one.
• Avoid calling “String.toCharArray()” – “toCharArray()” method is inefficient as the method reallocates the entire array stored in the string.  However, sometimes this is necessary.  Therefore, as a rule, avoid using “toCharArray()” method if possible.  If not possible, do use it with care.
• Place “try/catch/finally” block outside loop – Placing “try/catch/finally” blocks inside loops can slow down the execution of code. Do take note that moving the “try/catch/finally” block outside the loop can change program behaviour. An exception that has the “try/catch/finally” block outside the loop will terminate early.  On the other hand, the “try/catch/finally” block inside the loop may cause the program to continue iterating over the loop even after an exception has occurred.
• Use “StringBuffer.Append ()” instead of “+=” operators for concatenating strings – “Append()” has better improvement over “+=” operators and its recommended to use it instead of “+=” operators for concatenating strings.
• Do not use “StringBuffer” as constants – Dynamically resizable strings are unnecessary for constant strings (as they do not change).  Instead, use “String” for non-modifiable string constants.
• Do not open or close JDBC connections in loops – It is inefficient to open and close a connection in loop.  Instead, the connection should be opened before the loop and closed after the loop to avoid redundant calls make to the database.

• Handle the appropriate exceptions (checked); do not leave it to the unchecked exceptions – When an exception is thrown, the runtime system will exhaustively search all the methods on the call stack for the appropriate exception handler.  This is expensive and thus we want to minimize the search in the call stack in finding the appropriate exception handler to improve performance which can be achieved by throwing and catching the appropriate exceptions (checked exceptions).  Do not leave exception handling as an after-thought or code-as-you-go during development.
• Do not incorporate exception handling as control flow – As mentioned earlier, exceptions are expensive and should only be used for abnormality (planned and unplanned).  An if-then-else construct will perform better without the exception handling as there is no need to transfer control to locate the appropriate exception handling.   As such, review the codes and remove any throw statements from the coding that are used in an if-then-else construct.
• Avoid and remove the use of Reflection API in the codes – Reflection involves types that are dynamically resolved, which restricts optimization in certain JVMs.  Consequently, reflective operations have slower performance than non-reflective counterparts.  Therefore, unless there is a dire need for reflection to be used in the java program, it is best to leave it out if you need a high performance program.
• Let the system decide the garbage collection – If possible, remove any attempt to call system.gc(). system.gc() triggers a full collection , which includes tracing all live objects in the heap and sweeping and compacting the old generation. This can be a lot of work. In general, it is better to let the system decide when it needs to collect the heap, and whether or not to do a full collection.  Note: system.gc() merely signals (marks) the java program to do garbage collection, but it will not be an immediate garbage collection taking place.
• Reduce memory by avoiding the use of finalizers – An object is in the finalized state if it is still unreachable after running the finalize method, if any, has been run.  The finalized object is then awaiting deallocation and deallocation will not take place until the finalizer is run which is dependent on the VM.  The use of finalizer will extend the lifetime of the finalized object and it can be counter-intuitive when no deallocation takes place and when you intended to have the object being short-lived.   In order to avoid these short-lived objects being extended during the lifetime of the heap memory, it is best to consider the use of finalizers or free the resources explicitly.   (Source: Appendix A, The Truth About Garbage Collection and Java theory and practice: Garbage Collection and Performance)

How can we build a high performance web site through coding then?  Here are some basic tips you should note during development which should not be a big hassle for you to make changes anytime!

1. Remove any unused variables – The first thing and most simple thing you can do is to avoid creating unused variables.  Use static code analysers and look for variables that are initialized but not used.  Sometimes, in the midst of development, we leave out variables that aren’t used anymore and this can be removed to converse memory.

2. Free all resources – All created resources and variables should be released once they are not used.  This helps converse memory.  This will help optimize the memory usage and thus reduce the need for garbage collection cycle to take place.  Resources such as database connections and files are simple examples that you should close and release the resources.

3. Free all resources in the ‘finally’ block – Similar to [2], we want to free all resources.  However, this is catered to “unhappy” flow of the program code.  Free all resources that are used when exception arises if applicable.

4. Avoid calling methods in loops – This can be circumvented when the compiler optimizes the code.  However, if it doesn’t the loop condition will be calculated for each iteration during the loop

5. Avoid methods that may cause memory leaks – Methods such as split(java.lang.String), split(java.lang.String, int), substring(int), substring(int,int), nextElement(), nextToken(), nextToken(java.lang.String), group() and group(int) are candidates of memory leak.  There are quite a fair bit of search results on the methods that causes memory leaks.  You can refer to “Strings and Memory Leaks” from The Java Explorer for some information.  Avoid such methods whenever possible.  If not, do use it with care.

More to come on coding for high performance applications!  Share with us on your performance coding tips here too!

Of course, its not free.  To request an evaluation or see JSS pricing see the JSS Request page.  For more information of this extension, you can refer to the provider’s website at Zyntax Consulting.

About Zyntax Consulting, refer to Zyntax Consultin, About Us.

(Special thanks to Aravind Kumar for contribution, CSS Corp)

The error message that is thrown upon when the bootclasspath was not specified in the recording options is shown below:

To resolve the error was straight forward, enter the following to (a) the additional startup command to the recording options or (b) add it to the command batch file that is launching the Java application:

-Xbootclasspath/p:”D:\Program Files\LoadRunner\classes;D:\Program Files\LoadRunner\classes\srv”

1. Introduction

Before we start choosing Java-related protocols to perform recording, you will need to understand the protocol that the Java application is using to communicate with the server. It maybe the case where the Java application is communicating via HTTP rather than RMI-Java, etc… If you have identified that the application is communicating with a Java related protocol, you can safely proceed to choose the relevant Java protocol.

For Java-related protocol, the recording works in the same way as .NET and COM/DCOM protocol. All of them share the same characteristics but I will specify to just Java and only Java recording. Pure Java scripting will be excluded in this article.

Unlike .NET and COM/DCOM, Vugen provides an interface to manage and filter the classes and methods via the GUI which is very convenient to the user. Hopefully, Mercury/HP may consider that in future.

2. Classes and Methods

You will need the knowledge of the classes and methods prior recording; and usually this information is held by the developers. The need to know the classes and methods is crucial because, LoadRunner (Vugen) implements a hooking mechanism to hook the traffic on the classes.

If you do not know what classes are needed for the load test, and allow LoadRunner to capture all traffic on the classes, you may result in excessive capturing such as GUI clicks or client activities. On the other hand, if you did not specify the actual classes involve in the load test, you may miss out on the real class being used.

The above mention is based on the default Java hooking mechanism that LoadRunner implements. But if you required to have additional classess you need to record, you will need to configure the hooking mechanism that will be covered in subsequent post. This is also the reason the knowledge of the classes and methods come in important.

3. JDK and JRE

Other than the knowledge of the classess and method, you will need to know the JDK of the application. By default, Sun Microsystems JDK (SDK) works with LoadRunner.

There will be scenarios that your application is not using te Sun JDK such as IBM JDK. If that is the case, my advise is to check with Mercury/HP on the compatibility level and this will save you lots of effort. In my experience, usually they are not as fully supported as compared to Sun JDK.

The minimum supported JDK is JDK 1.3 for LoadRunner 8.1 as of this writing. Take note that the recording is still very dependant on the JDK version installed. That is, if your application is JDK 1.6, you will have to install this version on the recording machine.

Lastly, JRE is insufficient for the recording to be successful. Ensure that JDK is installed.

4. Recording-specified

LoadRunner Vugen implements an API that hooks into the selected classes and record the traffic. Therefore, as pointed earlier, knowing the correct classes to hook is crucial.

With the hooking in place, GUI classes or client-side activities maybe recorded via the hook. However, this is not recommended as it does not contribute to the load generation towards the server. I will share with you the recording details in another article. Do stay tuned for it.

5. Scenario Execution

Prior the scenario execution in the Controller, ensure that JDK have be installed on the Load Generators. The scripts sent (refer to the article,“4 points to note for Scenario Execution” for more information) are Java scripts, and require JVM to run.

6.Documentations

If you like to know more information from the official provider, you can refer to the Vugen User Guide that is provided in each installation of LoadRunner in PDF format. Specifically the following chapters:

1. All chapters in Part II: Working with Java Language Protocols
2. Chapter 18: Developing Corba-Java Vuser Script
3. Chapter 19: Developing RMI-Java Vuser Scripts.

7. Samples

Also, if you like to get a feel of working with Java protocol, I would recommend using the sample example provided with every installation of LoadRunner. It will at least get you understand what will happened and the expected output when recording Java language applications.

That comes to the end of the introduction of the workings of Java language protocol in LoadRunner, things to watch out and additional resources to pertaining to the topic. Do take note that Java is not as straight-forward as Web(HTTP/HTML) and therefore give it additional attention when working on such load testing projects.

This document is intended for an audience that is unfamiliar with the RMI-Java protocol or Java Technology. Follow the below procedures, step-by-step sequence to ensure that the Java application can be invoked and recorded properly. If you failed at any point of step, apply the appropriate solution before proceeding to the next step as the sequence below is designed to ensure that all requirements are met for the recording to succeed.

What we want to achieve in an overview is as followed:

1. Ensure the Java application can be launched outside Vugen.
2. Setup the Java environment for recording.
3. Ensure that an empty RMI-Java vuser can be replayed to verify Java environment.
4. Ensure the Java application can launch
5. Ensure the recording causes the “green box” to launch
6. Ensure the events are recorded after the “green box” launched.

This document also compliments Document ID 11878, “LoadRunner Java Environmental Requirements” which described the requirements needed for LoadRunner to record and replay Java-recorded scripts. Much is said, let’s walkthrough the steps together now.

[1] Launch the application outside VuGen

This is the basic verification as we want to know if the Java application can work first even before recording in Vugen. This will help to reduce the troubleshooting effort.

[2] Setup the Java environment

This is to setup all required environment as required in Document ID 11878, “LoadRunner Java Environmental Requirements” are met before we can proceed to record/replay on the local machine. Take about 15 minutes to read and go through the document.

[3] Verify the Java environment setup in [2]

Create an empty RMI-Java VUser and replay it. If the replay encounter no error, the setup is valid. If not, then rework on point [2] to correct the Java environment.

[4] Proceed to record the RMI-Java VUser

If all is setup properly and the supported JDK are installed, Vugen should be able to record. If not, proceed to [5].

5] If application does not launch during recording

The most likely cause of the problem is that the classes are not loaded which maybe missing from the CLASSPATH. Without the definition of the classes in the CLASSPATH, the application may not be able to launch. To resolve this problem, ensure the CLASSPATH is set properly.

a. Use javap.exe (available in JDK only) on the command line to check the missing method or class. To use javap.exe, run: javap.exe (without the “.class” suffix). When the class is not in the CLASSPATH, you will get the following error message: ‘Class not found’. Otherwise you will receive all its fields and methods. For more information of javap.exe, you can refer to MindProd and Sun Microsystem.

From here, look at the missing classes. If there are missing classes, obtain a copy from the developers of the application, and placed them into the CLASSPATH (including the classes directory you’ve defined for the recording).

b. Use Java-Plugin to identify the error message. Troubleshoot the error accordingly. For the plugin, it will throw the exception into its console. You will have to turn on the Java Console (in Control Panel > Java > “Advanced” Tab > Select “Show Console” in order to capture the exception or information. If exceptions were captured in the console, look at the error message and troubleshoot from there. As the exceptions may vary, you will have to see what is been thrown out in order to resolve the problem and we won’t be able to advise on it. (NOTE: The steps for the Java Console is based on JRE 1.5.0_06, therefore it may vary with other versions of Java Plugin.)

[6] If application launches but not recording (Green box illustrated below does not launch)

The problem can be caused where the default hooking mechanism is not loaded. To resolve the problem, follow the below suggestions for hooking mechanism.

a. Try running the -Xrunjdkhook outside VuGen via a .bat file. This is an easy way to verify the command statement with -Xrunjdkhook is working fine when invoking outside of VuGen. If it fails, you can proceed to (b), else look at the additional notes section to see if it fulfill any of the points mentioned.

b. Ensure that the hook files are properly set.

c. If you are doing custom hooking, verify that the hooks are properly configured with reference to the “Document ID 11287 – How to do Java custom hooking”.

d. Verify -Xrunjdkhook exist in the arguments passed to invoke the Java application. Below is a sample command line.

SET java -Xrunjdkhook -Xbootclasspath/p:\classes;\classes\srv -jar javaapp.jar

e. Ensure the file user.hooks is placed in \classes.

f. Verify the content of cjhook.ini

g. Look at the errors associated with hooking mechanism; this can be achieved with the following steps.

Enable in recording options > Recording Properties > Debug Options.
Enable all checkboxes, and set “Hooking Options” > “Printout Redirections” to “File” instead of “Console”.

After doing so, useful debugging information will be saved during recording in the file “/data/console.log”, and “/data/console2.log”.

[7] No events or hang recorded after Green Recording box is launched

This maybe a result of class files not correctly configured in the CLASSPATH. To resolve the problem, rework to step [5] and apply the solutions.

[8] Try on another machine

When all else fails, try it on another machine to verify if it is feasible to record the Java application. If this still fails, look at the Additional Notes section to verify if your Java application is compatible for recording.

Additional Notes

These are points to note when you are working with RMI-Java.

1. JDK vs. JRE

It is required that JDK be installed instead of JRE as JRE is not sufficient for successful recording

2. Is the JDK a supported version?

With the JDK information, it’s best to ensure the JDK is supported by Vugen (although it is highly dependant on the JDK that you installed). The supported JDK is Sun JDK. Other JDKs such as IBM JDK is not supported by Vugen and may need to engage consultation services to work around it or study the feasiblity.

3. Is QTP installed on the machine?

QTP may conflict with LoadRunner Java environment variables as Vugen maybe misled to use the QTP CLASSPATH. As such, you can either uninstall QTP or use another machine.

4. Record from a new machine

Sometimes, the settings on the problamtic machine maybe different and it will be an easy option to use a different machine to find out if there are any differentiating parameter between the two.

5. Importance of CLASSPATH and classes

Vugen rely heavily on the CLASSPATH to determine the classes to load for recording. Therefore, (1) always ensure the CLASSPATH has all the entries of the application before the recording and (2) the classes from the application existed physically in the classes folder that the CLASSPATH points to.

The above should sum up the steps to ensure successful recording. However, do take note of the points in Additional Steps so as to reduce the effort required to work with this protocol.