This blog will remain my performance testing blog. In the meantime, I've created a new blog at http://blog.sureshnageswaran.com/

This is to cover newer topics like offshorability of testing, the service provider's view, building a Testing Centre of Excellence (TCoE) and general testing research I've been running over the years.

See you there!

My punekar@yahoo.com account has been hacked and is unusable. I am discontinuing it.

Henceforth please contact me at sureshnageswaran@yahoo.com only.

[textile]

Saturday afternoon, I spent listening to the monthly SPIN lecture here at Pune. The speaker was *Prakash Khot*, a senior architect from *CA* (Hyderabad). The topic was the *Eclipse TPTP* (Hyades) project and open source in general.

One of the more interesting things Prakash mentioned was that CA consciously does not use GNU/products covered by the GPL copyleft license, preferring instead, their home-baked TOSL. What then are the implications for Mercury LoadRunner, which is based on the GNU *LCC*, GNU *Regex* engine and the GNU *GCPP*?

[textile]

In _*The Republic*_, _Plato_ conjectured on the idea of the dual level reality. One of these is known as the divided line:

!http://oregonstate.edu/instruct/phl201/images/philosophers/plato/divided_line.gif!

Above the line are the attributes of objective reality; below the line are the attributes of relative reality. This is not very different from user experienced times and response times measured from engineered tests. The problem, then, is to know whether a tool, even a favourite one, tells an objective truth or a relative truth! :)

[textile]

Comparing features among tools, especially performance testing tools, brings another dimension of complexity. The basic premise behind a performance test is to understand what response times can be expected by simulation of user traffic modeled along user actions. These response times may be TTLB (Time to Last Byte) measurements - and usually exclude browser render time. It is merely the time since the request was issued to the time the last byte of the response flowed into the network card on the machine. From the wire to a nicely formatted page on a browser is something not factored into the test.

[textile]
The most popular content on this site seems to be Anthony's comparison between *OpenSTA* and *LoadRunner*. I'm not surprised - Mercury's *LoadRunner* is the most popular tool in this space, but no company is hated more by it's user base. The first and prime responsibility for this anomalous situation must be borne by Mercury's corporate licensing department. A more hostile consumer licensing policy does not exist.

[textile]

That LoadRunner's recording engine hooks into browsers is a fact known to all those who've worked with the tool. What's not known is that the recording engine can also hook into non-browser applications at the same time it is hooked into a browser. As a result, the generated LR script will contain calls made by one browser and one external application.

Why is this of interest ?

Perhaps you have some VB/JScript code running in your browser that invokes a local DCOM server. This DCOM server in turn, makes some HTTP calls and you'd like that to be part of the generated script as well. But how do you trap that HTTP traffic in addition to what you're already doing?

A lot of documentation about the record/replay drivers has been included in the new Virtual User Generator User's Guide in 8.0. A separate chapter titled Information for Advanced Users documents much of this.

What is interesting is that the Binary VUser has also made it to the world of documented stuff. Another very interesting thing is the procedure to add newer protocols.