Truclient

[rpsd]

I have been using Loadrunner (now at 11.52 in my installation) for several years. I agree with James Pulley's comments about using the Web HTTP protocol for most business applications. While there may be some business applications for which the Truclient protocol is an EASIER protocol to work with, the key question is NOT whether a given protocol is easier to use, but does it result in a better performance test of the targeted business application.

Based upon my experience with the Truclient, HP really needs to improve the documentation associated with this protocol in their product. While you are in Truclient for Loadrunner development window, the lack of CONTEXT-LEVEL help leaves a lot to be desired especially for an ENTERPRISE class software package that Loadrunner is supposed to be. For example, just open up the details of the ANY of the steps that have been recorded in a Truclient script. If you expand the Step details, you will see several options that have drop-down list boxes associated with them. Two of these options are the Action and the End Event options. However, the  Loadrunner Vugen Truclient software provides NO CONTEXT LEVEL HELP for any of the values associated with these options. While the performance engineer may be very familiar with the protocol used by the application, does he/she have to GUESS at what the Loadrunner software does with this wide selection of values or how different combinations of these values interact with each other?

What HP should have done by now, since Truclient has been around for a while, is provide a book which describes the usage of this protocol with actual case studies from some web applications that are excellent candidates for this protocol. This book should go into the details of handling the common frustrating problems on errors like, "target object not found", parameterization, when to use custom javascript, why the script works perfectly in Vugen DEVELOPER mode, but always fails in Vugen LOAD mode or in Controller mode and the problems incurred when dealing with asynchronous applications. This is commonly done for other applications in FREE publications like the IBM REDBOOK series.

Consider this problem that I commonly run into when using Truclient. You have an Ajax application that has a drop-down list box with several values associated with it. If you record the selections of a value from that drop-down list box, the Loadrunner Truclient software will record ONE event. Within that event the Step section specifies the "Select" value under the Action option. Replaying this script works perfectly in DEVELOPER mode. However, the script always fails with "target object not found" in Vugen LOAD mode or in Controller mode. If you change the script so that 2 EVENTS are used in place of the ONE EVENT that was recorded, the problem no longer occurs In this case, the following 2 events solved this problem:

1) Click on <object> listbox (Note that Click is the value of the Action option under the Step section of this event.)

2) Select <value from drop-down listbox> from <object> listbox. (Note that Select is the value of the Action option under the Step section of this event. Also, this was the ORIGINAL event that was recorded by the Loadrunner Truclient software.)

I am also currently having a problem with a CHECK BOX object on another page of this same application. I tried a suggested solution of creating a Generic Object Action event in place of the RECORDED CHECK BOX event but I am still getting the "target object not found error in Vugen Load mode or in Controller mode.

For a product as expensive as Loadrunner is, this  better documentation would go a long way in removing many of the problems performance engineers are having with this protocol.

[Runner53]

I have been using LoadRunner as my primary performance testing tool for 14 years, since version 5. I previously was adamant about sticking with the LoadRunner Web (HTTP/HTML) protocol for testing the majority of our applications. However, times they are a changing. I am now 99.9% converted to Ajax TruClient.

 

While I will agree that HP has done a terrible job documenting or even keeping up with the use of their own protocol, I have found TruClient to be ideal as a starting point for testing our applications. The time our team can save putting together working scripts is significant and this is very important in our environment, because our team generally only has an average of a week from end-to-end to engage with the Project Team and deliver results. Add to this fact the reality that the Web (HTTP/HTML) protocol is a nightmare to try to use for Web 2.0 (Ajax, Javascript, Flash) applications, and Ajax TruClient is our "default". There is probably only one main exception to this rule for us: Web Service testing. Otherwise, we start with Ajax Tru Client, and, if we cannot successfully use this protocol we "drop back" to the Web (HTTP/HTML) protocol. Complex correlation is still the primary drawback to the Web protocol, and finding ways to manage the Ajax and Javascript stuff adds significant time to script development.

 

The challenges presented with the use of the Ajax TruClient protocol, though different than those I found with the Web protocol, are generally easier to overcome. The testing results presented to the Customer are easily at the same level, though the definition "transaction response time" may be different now. We can at least get closer to the type of turn-around our customers demand, and that is the main driver for us. 

 

My testing colleague, Shawn Wales, will probably be quite surprised by this posting by me. Actually, if everyone had Shawn a phone call away, the use of Ajax TruClient would skyrocket. He has figured out things that can be done with this protocol that HP doesn't even know about yet. As a statement of fact, HP does a horrible job supporting LoadRunner, period. Web Protocol, Ajax TruClient Protocol, SiteScope, whatever.

[Stimely, Noelle]

I am in complete agreement with this thread.  The correlations when using HTTP protocol are horrific and take away from valuable time which could be devoted to designing a realistic load test.  I too am usually not given much lead time for running load tests and my customers do not understand why there are significant delays when using HTTP protocol.  It looks bad on my end as it seems I am “not up to the task” for load testing.  It is a huge confidence loser!  The only significant drawback for the TruClient protocol is the cost which is significant in addition to the regular license. 

 

Regardless of cost I highly recommend the TruClient protocol as it is much easier to use than HTTP unless you love digging through lines of spaghetti code for hours on end!  I have better ways to spend my time!

--
You received this message because you are subscribed to the Google Groups "LoadRunner" group.
To unsubscribe from this group and stop receiving emails from it, send an email to LR-LoadRunne...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.