3

HP Loadrunner support many protocols like http/https, SAOP, Oracle NCA etc. It also has server monitors which are able to produce server statistics for many different servers. what is the technology behind Loadrunner? What protocol is used for remote calls between Loadrunner VUgen and Loadrunner controller?

9ikhan
  • 1,177
  • 3
  • 11
  • 22
  • I wonder how one can find already-answered questions of the "in what language is commercial product X written in" at stackoverflow (or other StackExchange sites, for that matter). – TheBlastOne Apr 18 '11 at 11:33

4 Answers4

4

Controller seems to be written in Delphi, or Borland's ancient (now-vanished) C variant of it.

VUgen appears to be a native C application, with the editor being SlickEdit (see http://en.wikipedia.org/wiki/SlickEdit).

The C interpreter in VUGen is not neccessarly SlickEdit's Slick-C, but I am pretty sure it is a licensed commercial product.

The protocol for the online communication between controller and a VUGen-created LR tests probably is proprietary, I think RPC-based. You could dig through the admin documentation where the open ports required are documented, that might give enough hints to guess the protocol.

TheBlastOne
  • 4,291
  • 3
  • 38
  • 72
  • If I remember correctly, the C debugger in VUGen is actually based on LLC – Gareth Davidson Mar 17 '11 at 13:35
  • To whom it may concern: TestDirector used to be a Delphi-written product, too. I think the last version of QualityCenter that was still called TestDirector was the result of a Java port, i.e. they ported the server code from Delphi to Java. Time will tell if this was a good idea :) but probably, and unfortunately, it was. – TheBlastOne Apr 18 '11 at 11:29
  • This answer is incorrect even for the version that was available when it was asked (11.0). For version 11 Controller is C++ with C infrastructure for communication with LG. The schedule graph and some monitors are written in Delphi but only the UI bit of them, all the logic is C++. VuGen 11.0 is mostly C++ with C infra, VuGen 11.5X and above is C# with C# infra and some UI elements are from the old VuGen and hence in C++. – Buzzy Mar 30 '14 at 11:31
  • How can an answer giving suggestions like "seems to be" or "appears to be" be wrong when the reasoning behind those suggestions is included. If you have a better answer, feel free to post it. Remember to back up your claims with references to your sources, then. (OP has the possibility to accept a different answer if he/she thinks it is more helpful. Instead writing comments that say "I know better" is NOT helpful, nor is it polite. Think about it.) – TheBlastOne Apr 02 '14 at 08:56
  • I work on LoadRunner for 4.5 years now (since 11.0) so I have some idea on the technologies used :) – Buzzy Aug 14 '14 at 08:50
  • You are welcome to edit the question so it reflects more of the reality, and has less of the "guessing" nature, of course. (At least I would not have a problem with it.) – TheBlastOne Aug 18 '14 at 09:05
3

C/C++

VUGEN and Controller do not communicate: The Load Generator and the controller communicate. It is a custom protocol which supports both file transfer as well as handshake between controller and load generator during the test window.

If you dig deep into the bowels of LoadRunner you can find many interesting bits, including those which tie back to SlickEdit on the VUGEN front. Look through the files, the readme's the license docs and it will tell you quite a bit about the architectural components that LoadRunner is built on top of.

James Pulley
  • 71
  • 1
  • I agree. And if you look at WinRunner, and its internal structure, you will find it might be a sister of LoadRunner's, with both sharing common roots in a hardware/software combination product called TestRunner which was the first product of Mercury in the (I think) early 90s. While I am not sure about the TestRunner aspect (I know it existed, though), I am let's say 70% sure that LoadRunner and WinRunner have a common history in which they might have shared a common code base. – TheBlastOne Apr 18 '11 at 11:32
1

You're referring to different products/applications that are built on different technology. A few comments to what you're asking

I don't think that there are any calls between VUGen and Controller. VUGen works on protocol level and it's output is a script with resources (static zip file). Controler takes zip file as an input and executes scenario that's defined in Controller itself. There's no need in any API calls or even in having VUGen installed when you're running tests in Controller

Collecting stats from servers is usually done via SiteScope for Loadrunner. You may easily understand which language is it developed in by looking at folders and files.

Sergey Stefurak
  • 161
  • 4
  • I disagree -- Controller does not take ZIP files as input. It references LR tests, which consist of a whole directory structure per test, which is exactly what VUGen spits out. That structure is replicated to the load generator (maybe in the form of a ZIP file?), and used by a kind of "exec-only" VUgen to execute the script with a C interpreter. – TheBlastOne Mar 14 '11 at 12:11
  • actually zip file contains the directory structure with all the files (See 'export to zip option') and is a convenient way to store/pass tests across machines and products. Anyway mymain point is that there's no need in any API calls between VUGen and Controller. There's no need to have vugen at all when you run scenarios in Controller - you may have just a test either in zip or in original format. If I'm not mistaking load generators/replay engines are taking a scenario as command line with a lot of parameters including scenario details and test (unzipped one) location on the disk – Sergey Stefurak Mar 16 '11 at 12:04
  • I see. But inhowfar does Controller consume the ZIP files that result from "export to ZIP"? – TheBlastOne Mar 17 '11 at 09:49
-1

It's closed source, so there isn't really any public proof of stuff like that. My best guess would be C(#?) though.

McKayla
  • 6,879
  • 5
  • 36
  • 48
  • 2
    Well the main question regarding the language LR is written in can indeed be answered even though it is closed source. You can inspect the binaries and will find traces of what is typical, if not unique, for certain runtime systems. Also, certain resources are structured in a way that indicates which dev env was used to create and deploy (or link) them with the executeable. – TheBlastOne Mar 17 '11 at 09:51
  • It definiteley is not C#, LR is much older then the first C# design paper. – TheBlastOne Mar 17 '11 at 09:52