punekar
12 years agoOccasional Contributor
Solution: Transaction response times in LoadComplete
So, those of you from the LoadRunner world are probably wondering why you're restricted only to page level response times in LoadComplete as opposed to an atomic transaction response time that spans multiple requests.
With the absence of scripting in LoadComplete, this may not seem doable.
However, my team here has come up with a solution involving LAMP or at least Apache/PHP/MySQL.
Outline:
1. Run an Apache server on the LoadComplete Controller machine to host some PHP pages (to be described).
2. In your scripts (scenarios in LC parlance), make calls to these PHP pages *before* you send requests out to the target application under test.
3. Make the requests to your Application Under Test (AUT).
4. Once done, make a call to the PHP page *After* to let the page know the transaction is completed.
How it works:
* You have PHP pages hosted on Apache for the following:
- Create a unique VUserID and send it back on the response ( LoadComplete really should have had this capability out of the box as a parameter)
- "Start" a transaction - essentially, a page that records that such-and-such VUserID running Iteration #n has started a transaction called "XYZ" at such-and-such time.
- "Stop" a transaction : identical to the one above, except this stops the aforementioned transaction.
The transaction PHP pages will write these records to a MySQL database.
This kind of solution can be extended to do all kind of neat things including -
* Manipulating data in code, returning what we need
Without scripting in LoadComplete, you have no other way to do something like this.
As an example, lets say the AUT gives me a response page with 20 items. And I want to select one of these randomly to pass into the next request to the AUT, this can;t be done in LC without scripting. And of course, there is no scripting. Doing your data manipulation in PHP, returning that in a response for LoadComplete to capture into a parameter will work.
* The equivalent of VTS tables in HP LoadRunner
Virtual Table Server (VTS) helped running VUsers to exchange data at runtime. Of course, this required responsible coding.
I'll be attaching sample code as we go along.
With the absence of scripting in LoadComplete, this may not seem doable.
However, my team here has come up with a solution involving LAMP or at least Apache/PHP/MySQL.
Outline:
1. Run an Apache server on the LoadComplete Controller machine to host some PHP pages (to be described).
2. In your scripts (scenarios in LC parlance), make calls to these PHP pages *before* you send requests out to the target application under test.
3. Make the requests to your Application Under Test (AUT).
4. Once done, make a call to the PHP page *After* to let the page know the transaction is completed.
How it works:
* You have PHP pages hosted on Apache for the following:
- Create a unique VUserID and send it back on the response ( LoadComplete really should have had this capability out of the box as a parameter)
- "Start" a transaction - essentially, a page that records that such-and-such VUserID running Iteration #n has started a transaction called "XYZ" at such-and-such time.
- "Stop" a transaction : identical to the one above, except this stops the aforementioned transaction.
The transaction PHP pages will write these records to a MySQL database.
This kind of solution can be extended to do all kind of neat things including -
* Manipulating data in code, returning what we need
Without scripting in LoadComplete, you have no other way to do something like this.
As an example, lets say the AUT gives me a response page with 20 items. And I want to select one of these randomly to pass into the next request to the AUT, this can;t be done in LC without scripting. And of course, there is no scripting. Doing your data manipulation in PHP, returning that in a response for LoadComplete to capture into a parameter will work.
* The equivalent of VTS tables in HP LoadRunner
Virtual Table Server (VTS) helped running VUsers to exchange data at runtime. Of course, this required responsible coding.
I'll be attaching sample code as we go along.