What’s new in LoadRunner 12?

LoadRunner 12

The roadmap for LoadRunner 12 was presented at HP Discover Barcelona in December last year. Since that time, I’ve been lucky enough to have a beta copy of LR12 for evaluation purposes. Now that the product has been released, I’m able to share some of the new features that I’ve found to a wider audience.

Key observations / new features are:

Cloud-based load generators. HP describes this feature as “cloud bursting”. Users now have the ability to provision load generators on AWS (Amazon Web Service) cloud servers from within LoadRunner or Performance Center. As well as this, the ports used to communicate between LoadRunner components such as Load Generators, Controllers, MI Listeners are user configurable through the new “network security manager” tool. This simplifies the setup process and allows more flexibility in distributed test networks or cloud-based test environments.  It is even possible to configure different ports/proxies for each Load Generator.

Licensing – 50 vUsers free
We in the user community have been asking for this for a long time. Providing fully-functional applications that allow small-scale testing allow prolonged evaluations and proof-of-concept exercises. This is great, because it allows more people e.g. developers to get hands-on experience and see the potential benefits of using LoadRunner.

This is likely to improve the adoption rate for LoadRunner and prevent the erosion of market share to low-cost / no-cost providers of performance testing software.

All protocols are included in the “community edition” license, with the exception of GUI (UFT) and COM/DCOM protocols as well as those protocols in the “template” bundle (i.e. those vUser types whose scripts are manually created (rather than record/replay) such as C# .Net, VB .Net vUsers).

VUGEN improvements
There are a variety of improvements as you would expect. Key ones are:

  • The ability to review replay statistics for tests after each run.
    Including details on total connections, disconnections and bytes downloaded.
  • The ability to edit common file types in the editor.
  • Support for recording in the Internet Explorer 11, Chrome v30 and Firefox v23 browsers.
  • The ability to create scripts from Wireshark or Fiddler files.
  • The ability to record HTML5 or SPDY protocols.

 

TruClient improvements
TruClient script converter. This basically replays your TruClient scripts and records the HTTP/HTML traffic allowing you to create these script typers from TruClient recordings. This is similar to recording GUI scripts and then converting to other script types.

The addition of support for Rendezvous points, IP spoofing, VTS2 and Shunra network virtualisation in TruClient scripts.

Linux Load Generator improvements
Building on the increased support for Linux Load Generators in 11.5x, LDAP, DNS, FTP, IMAP, ODBC, POP3, SMTP and Windows Sockets scripts can now be replayed through UNIX load generators.

CI/CD support
Better integration with Jenkins etc.

Platform support

  • Support for installation on Windows Server 2012.
    (LoadRunner 11.x and PC 11.x only supported up to W2K8 which was a barrier to enterprise adoption).
  • LoadRunner components can now run in a “non-admin” user account with UAC and DEP enabled.

There are numerous other improvements which are well documented in the “About LoadRunner” section in LoadRunner help. Now that the community license is available, there’s nothing stopping you from downloading it and giving it a go.

To get your own copy, navigate to www.hp.com/go/loadrunner  and follow thre links to download LoadRunner.

– reproduced from my Trust IV blog article at:
http://blog.trustiv.co.uk/2014/03/first-look-loadrunner-12#sthash.pmwREa11.dpuf

LinkedIn discussion groups….

 

I just stumbled across another LinkedIn discussion where a group of offshore testers were trying to explain to each other the difference between “throughput” and “response time”.  Their explanations and counter explanations run to several pages.  I scanned through the names and (offshore) companies involved and I’m glad that none of them are on my payroll. 🙂

 

 

It reminded me of the article that I wrote in December for the Trust IV blog recently. “Caveat emptor when selecting an offshore partner”. I’ve attached a PDF transcript of the discussion for those of you don’t have the dubious honour of being a member of the “Performance Tuning Tips” group on LinkedIn.
Is it any wonder that businesses undervalue performance testing when it’s conducted by people who obtain all of their knowledge from LinkedIn and GoogleGroups?

pdf icon
Download LinkedIn Discussion Transcript

 

Come on Asda, sort your website out or face losing market share….

© Copyright Rich Tea and licensed for reuse under this Creative Commons Licence

My wife is a regular online shopper and is a little more tech savvy than the average shopper. She’s heard me “banging on” about website performance for long enough that she knows that when one browser doesn’t work she should try another, or use a different PC (as a geek household we have several!)

We’ve used Asda’s Click and Collect service since it started in our area and have used their Home Delivery service for several years.  Over recent weeks, my wife has been complaining that their website seems slow; she’s experienced several browser crashes when adding items to orders and is becoming generally dissatisfied with the website’s performance. She described this to a delivery driver recently and he mentioned the fact that deliveries were “quieter than normal”.

My wife told me that the Asda website had performed poorly with Chrome, IE and Firefox browsers on her Windows 7 PC. I confirmed the same behaviour on my PC. Rather than adding additional items to the order I gave up and basically decided that we’d accept whatever was delivered. My wife persevered and finally managed to amend the order late last night on an iPad using the Safari browser. (She’s very persistent) 🙂

This morning, I decided to take a closer look at the Asda website. I installed DynaTrace AJAX Edition on my PC and monitored my IE browser as I logged into the Asda website. I wasn’t surprised to see poor performance in client-side code.

dt1

The home page and the groceries pages both respond in a few seconds, but when I logged in and clicked on the page showing my favourite items (i.e. those that we order most frequently), the page took 9.5 seconds to appear in my browser. The bulk of this time was spent executing client-side JavaScript (shown in orange in the image below).

dt2

I’m not testing the Asda website, but if I was… I’d start performance testing whilst simultaneously using APM tools like DynaTrace, HP Diagnostics or Introscope; this way I could give detailed feedback to the developers. I’d also want to use performance test tools that are capable of executing client-side code such as LoadRunner, SilkPerformer, SOASTA CloudTest or NeoLoad. This is preferable to using low-cost/no-cost HTTP-only tools like The Grinder or JMeter.

Now I’m not a developer, but if I was…
I’d be paying particular attention to the following functions:
function navigateToFavouritesListsPage  (Total execution time – 11.8 seconds)
function getPCookieName  (This was called twice and took 3.5 seconds)

For Asda’s sake and that of the delivery driver who is reporting deliveries being “quieter than normal”, I hope that they sort this out soon. My wife for one would be grateful.