Subject: LR JDBC Protocol
Hi Stuart,
I have a Java Swing-based client that communicates directly with a database server using JDBC. What are my options for recording this application with LoadRunner
Thanks,
Jxxxx Cxxxx.
As you probably noticed, there is no native vuser type which will record your application successfully. Fortunately, you still have several options for recording your application.
Option #1 – Winsock (a bad option)
If you record your application with a Windows Sockets vuser, you will see uninteligible data being sent and received.
Just because you can record something with a Winsock vuser doesn’t mean it is a good idea to try to create a script with this vuser type. The rule-of-thumb is don’t try it unless you can understand what you have recorded at a glance. This means avoid any incomprehensible binary formats and only use Windows Sockets recording for the simplest text-based protocols.
Option #2 – Citrix or Terminal Services
Citrix vusers (and, with the release of LoadRunner 9.0, Terminal Services vusers) are kind of like a get out of jail free card for applications that are difficult to script. Rather than recording the network traffic between your client and the server, these record the traffic between your Citrix client and the server that is running your application client, giving you scripts that describe what is happening to the GUI (e.g. ctrx_mouse_double_click(), ctrx_sync_on_window() etc.)
The downside to this approach is that you will…
- need to be licensed for LoadRunner Citrix (or Terminal Services) vusers.
- need to have access to a server to run many Citrix sessions on. As you are adding another layer to your test, you must ensure that the Citrix server is not the bottleneck when running your load test.
- need to have enough Citrix licenses to run your required number of virtual users.
Option #3 – QuickTest Pro vusers
LoadRunner has an option to run QuickTest Pro scripts instead of scripts created with VuGen. As with the Citrix vusers, your scripts are interacting with the GUI of the application you are creating the script for, so you will never have to worry about any difficult correlation situations.
The downsides are…
- You need a special LoadRunner license.
- You will need a separate QTP license for each vuser you intend to run; e.g. if you want to run 100 virtual users, you will need 100 QTP licenses. This rapidly becomes expensive.
- You will only be able to run 1 vuser per load generator, so to run 100 virtual users, you may need to find 100 workstations and install QTP on them. You can increase this slightly by fiddling with VMWare or Terminal Services, but you will still need lots of generators.
- As it operates through the GUI, it requires extra time to identify objects. Using WinRunner vusers in the past, I would get radically different response measurements between my WinRunner vusers and my web vusers.
Option #5 – Buy from a third-party
On June 13 2007, Clay Roach from J2EE 911 announced that they would be releasing a LoadRunner JDBC protocol through the HP partnering program.
J2EE 911 announces HP LoadRunner and HP Performance Center protocol extensions for the Java/J2EE platform – including the first pure JDBC Protocol which can be used in conjunction with existing HP LoadRunner scripts to test and validate database data on any database that supports JDBC. The JDBC protocol will allow customers to harness their existing investments in HP Quality Management and enable quality assurance (QA) and development teams to easily collaborate and ensure scalability of their Java/J2EE applications.
The new protocol hasn’t been officially released, but Clay will be happy to discuss licensing options for this product, and may make an early release available to you if you ask nicely.
Option #4 – Java recording with Custom Hooks
The Rmi-Java and Corba-Java vuser types (which I have written about previously) behave differently to other vuser types. They hook into the JVM and record the method calls and arguments to the methods, and generate a Java-based script with the same API calls that your application makes.
The RMI and CORBA methods that LoadRunner hooks to record these scripts can be found in \LoadRunner\dat\rmi.hooks and \LoadRunner\dat\corba.hooks.
An example hook might look like this…
[CORBA_2_3-ORB-init1]
;---------- ORB.init ----------
class = com.sun.corba.se.internal.corba.ORB
method = init
signature = ()Lorg/omg/CORBA/ORB;
cb_class = mercury.corba.CORBASupport
This hook instructs LoadRunner to hook (add extra code to the class as it is loaded to record method calls and object values) the init method in the ORB class in the com.sun.corba.se.internal.corba package.
It is possible to define your own hooks in \LoadRunner\dat\user.hooks
; This is a sample hook -
[Hook-Name]
;---------- ClassName-MethodName --------
class = MyPackage.MyClass
method = MyMethod
signature = ()V
cb_class = mercury.ProtocolSupport
general_cb = true
When choosing which classes and methods to hook, you will generally pick any which send network traffic, so for an application which communicates using JDBC, you would choose all of the JDBC methods (which can easily be found in the java.sql and javax.sql Javadocs).
There is further information in the Hooking “General” Java API calls with LoadRunner document, which was in the Mercury Support knowledgebase until HP took it down.
I would not advise that you try this approach unless you are competent at programming with Java.
