Recently I conducted a comparison between two LoadRunner recording protocols, HTTP/HTML and HP TruClient. The aim of this exercise was to discover what benefits HP’s patented TruClient protocol would offer on a project when compared to the more traditional HTTP/HTML approach.
Having done some background research on the TruClient protocol, I was keen to test the main benefits TruClient offers as well as the main downside, all of which I have listed below:
TruClient’s main Benefits:
- Less scripting time
- More accurate representation of end user activity
TruClient’s main Downside:
- Memory Intensive
Having looked at the two main benefits, it’s obvious to see why TruClient is appealing. In testing, it’s common knowledge that scripting against some application can be challenging and time consuming. Especially when you consider that the majority of business applications fall under the web 2.0 banner, which brings with it a whole new challenge to scripting. Fortunately HP has an answer in the form of TruClient for which I have rated it on various categories.
- Project phase: Build
Approaching this with a somewhat sceptical mind-set, I was pleasantly surprised to see I was able to create an automated script that played back end to end, in about 5 minutes!
Recording the same business process took the same amount of time; however when I played it back, various page calls returned an error page. In order to fix this issue, I had to write some code to add a header to those calls. This code is something I had to work out and was not generated during recording. A blocker like this could realistically prevent a script from working end to end for days until a resolution was found.
When observing both protocols ability to record and playback a script, TruClient wins hands down. And after testing TruClient against some more applications, I am convinced this is one benefit which can have an instant impact of the time spent during the build phrase.
- Project phase: Build
Record and playback is only the first part of the process. In order to create a realistic script, you need to make the script ‘smart’!
Various enhancements need to take place ranging from the easy stuff such as adding transaction wrappers, to the more challenging stuff such as simulating various dynamic user actions.
When it came to enhancing the script I felt there was no noticeable benefit when compared to the standard HTTP/HTML approach.
There’s no escaping the fact that smart scripts require custom code in them to be dynamic. However because TruClient scripts are GUI based and made up of a series of action blocks, it’s difficult at first to visualise and apply the necessary code in order to create the effect you want. I often found myself wishing I was looking at a flat script rather than spending ten minutes working out how to drag an
IF-statement block into the correct place.
The approach does work; it just takes time to get used to. TruClient has obviously attempted to present scripts in a more abstract way, in an attempt to reduce the level of technical know-how to create them. However coding will always be a part of scripting, and so learning how to apply code to GUI based scripts is a must, it just takes time to relearn the process again.
Enhancements are done by adding code to a recorded non GUI script.
At first TruClient can seem a bit daunting when it comes to script enhancement because it feels like you’re learning a new tool all over again. However once you get over the initial hurdles and start to feel comfortable with this scripting approach, you find it to be quite intuitive and somewhat elegant.
Although I was more focused on the scripting side of things, I did however have a chance to do some comparisons between both protocols during a load test. The aim of this test was to see just how intrusive the memory utilisation was for TruClient.
In my test I ran 20 users all doing the same business journey. 10 users were from the TruClient script and 10 users were from the HTTP/HTML script.
I noticed the TruClient script created a separate process for each user in memory, resulting in a total of 10 processes running at an average memory usage of 70MB per user. That’s means my computer required at least 700MB free RAM just to run 10 users!
Compare this to the HTML/HTTP script which only required one process in memory running at around 20MB for 10 users. That’s equates to TruClient being 35 times more memory intensive!
If you are going to use TruClient, ensure you have plenty of physical resource in your load injectors.