loadrunner Hi all In my current project we have desktop...

  • Thread starter Komirelly Srinivas Reddy
  • Start date
  • perf-test.com need your contributions to build up a strong repository of performance engineering resources.

K

Komirelly Srinivas Reddy

Guest
Hi all In my current project we have desktop application for which we are doing a POC. The application is developed in Java swings. Iam not able to records the desktop application. Can anyone how to record desktop application.
 
Try with win socket protocol, but as a first step try analyze application in Loadrunner using protocol analyzer it will help u to choose which protocol for ur application
 
Swing is the library to develop the GUI part. Which technology was used to establish communication with the server?
 
Of the application uses HTTP protocol, obviously you should use Web (HTTP/HTML). In case you're not getting anything recorded you should configure proper Port Mapping
 
try with Java Record & Replay, Java Over Http or Web Http Html...you can get the api from the development and use it in java vuser protocol as well
 
Architecturally, how does your Java Swing application communicate to the next upstream architectural component? CORBA? RM/I? Sockets? HTTP? Each requires a different path to develop a piece of test code. Or you can take the path of leveraging your source code with a Java Virtual User. Or you can move to the top of the stack and leverage a GUI Virtual User. Or, if you have a Citrix infrastructure you can leverage a Citrix Virtual User. Or, if you have a Terminal Services infrastructure, then you can leverage a Remote Desktop Virtual User.
 
James Pulley..I have a doubt around RDP simulation, will it not cause client side issues as during test multiple thick clients will be opened on same machine which is never expected in production scenario? It may saturate client resources or if not saturate can have negative impact on results as that is not a production like scenario.
 
You would run these in terminal server. Each GUi would have a singular OS instance on Terminal Server and one application instance running in the OS instance. As an alternative you could spin up several hundred Windows virtual machines in Amazon or another cloud provider and on each run a single RDP session with a single instance of the application. Your call.
 
How is the case with citrix? Also will the response measured be accurate or will it contain some overhead due to RDP or citrix interface?
 
Citrix is also a multi-user operating system variant, with each user receiving their own OS instance for the execution of software. Both Citrix and Terminal server are architectural cousins in this case. Will there be overhead enough to distort the performance of users? Yes, that can be the case with any load generator for any virtual user type. The trick is to both measure the finite resource pool on the load generators as well as to introduce control factors into the test design to highlight any performance issues on a particular load generator which would impact the response time measurements. There are two classical models for control factors. The first is a control application. This is running side by side with your application under test. At the beginning of the test you start a small number of users running light tests on the control application. This load is small enough that the performance of the control application never distorts on the server side. The only distortion then comes from a load generator which is under load resulting in response times which degrade due to machine resources. You can watch this in the controller and if you observe the control group degrading with the virtual users for the application under test then you have a load generator induced affect on the response times. The second model is the one I prefer as it does not require the use of a control application. This one involves the user of a control load generator. In this model all load generators are hardware/software matched and you have at least three load generators (two for primary load and one for control) in addition to the controller. You may have more than three, but I see three as a minimum set. Take one virtual user of each business process type involved in the test and place them on the control load generator. Design your scripts to allow for these users to create timing records (transactions) which are distinct in name, such as generating Login_Hostname or Login_Control in addition to the transaction Login. You can watch in the controller during the test execution for differences in behavior between the control group and the Global group. If you observe that the global dataset for Login is getting slower but the control group for Login_Control is unaffected or perhaps is getting slightly faster, then you have a load generator induced affect on your response times for the primary load generators. On the other hand, if you observe that both the global and control data sets degrade at the same rate, then you have a common source to the degradation, which is the application under test. Another benefit of having a control dataset is that if becomes very easy to pull this out and discuss its use when you have a developer or project manager who doesn't like the results and wants to blame the test. You can point out that you have incorporated a number of control elements in the test to identify if you have a test design created issue versus and application under test issue. It will raise your respect in the eyes of those who would dismiss your results immediately after the discussion.
 
Thanks James Pulley for sharing this, also what is the impact of OSI layers on response time measurement? For example simulating with Winsock which is lowest in OSI in comparison to RDP which is at top of OSI and would also include thick client logic execution?
 
Yes, the GUI will always add some weight. The complexity of the client will determine how much weight. As an example a terminal emulator on top of Winsock. The added overhead of the processing from Winsock to a Telnet representation in a terminal emulator os very low. With a Java Application you have the GUI and all of the application code is running inside of the Java VM. That adds a reasonable amount of overhead even for non complex client applications for all of the Java Items which have to be thunked to the native OS for resource access or GUI representation. Citrix and RDP are designed to be really thin layers, so their overhead is generally very small, unless you wind up on an overloaded Citrix/terminal Server node which should be rebalanced. For me, I try to move to the lightest weight virtual user possible, because this provides the cleanest view of the server performance without the introduction of client bound code. Where that is not possible, you have to move up the stack to drive the application. As noted above, "Java Record ReplaY" wasn't working to pick up the stream. This could be related to versions, environment, that nothing Java protocol specific was used in communication to the hosts, a lot of possible reasons. So your options are to debug and find the right protocol or move up the stack to drive the GUI.
 
Hi please install only the advised Java version on the machine. If you have multiple versions of Java it may cause this problem.. Kindly give a try and revert
 
Are u able to launch the application? Or you not able to view anything in the application after it is launched?
 
Can any one help how to integrate the load runner tool with desktop application as iam not able to launch application when recording the script.
 
when you click on Record, to record your flow, r u using Web Browser option or Windows Application option?