Contributions
Re: How is it coming from LoadRunner? ...
Sergei - Thanks for taking time to respond. You will have to change your mind sooner or later about exposing the scenario/script format to users. Mercury/HP tried to keep this under wraps for the longest time and didn't succeed. People reverse engineered it and figured out the mechanics. Today everyone knows about the LCC precompiler and their custom object format. It helped for a more "aware" user base who would comprehend runtime issues with controller/generator communication etc. Key takeaway - Information, and openness, is better than a black box philosophy. Also, the results format today has to absolutely change. You have to populate it into either CSV or database. There is really no reason why users should not be in control of their own data. All you have to do is output raw numbers to CSV to make it immediately useful. We can then import it into spreadsheets and do our own reporting from there onwards. Please tell me there is a plan to ensure this is happening in a future release. About support for other protocols - why not include support for a compiled virtual user? Let us write our code in Visual C++, compile to object format, and have LoadComplete simply invoke that compiled code at runtime.2.5KViews0likes0CommentsRe: How is it coming from LoadRunner? ...
Chris - It's great to see you here on these forums. I've had to recently make the transition from LR to LC in the last six months. My key observations are as follows: The key thing to realize is that this tool is not LoadRunner. That's why it's an order of magnitude (almost 20x) cheaper than HP LR. Having worked with LoadComplete in 2 different firms, I find their USP is product support. They are quick to provide fixes, most of them inside of 2 days. The support staff also works collaboratively to devise solutions to the specific issues you have. Above all, their product development team and Director are reachable in case of issues. When I compare this to my experiences with HP, it is night and day. Once you understand that this is a maturing platform, you will be able to build scripts rapidly. Some other notes: 1. The tool is more black box than white box. In the sense, their scripts are stored in a proprietary format as are the result files. This has caused me some irritation in being able to edit them outside of their editor interface. Hopefully, this will change. I've had conversations about putting their scripts in an open format and logging results to databases instead of JSON objects in flat files. 2. Their regular expression support is robust. However, they can only catch one expression in a variable. I've asked for the ability to capture an array of matches as opposed to just the one. Again, it's not clear in what release this feature will show up. 3. Scripting support is not there at the moment. This means any custom modification of variables, string manipulation has to happen outside the tool. We have devised a mechanism to get around this limitation and so far it has worked fine. However, I have had a lengthy discussion with the Product Director on this and have been promised full scripting in the coming quarters. Sergei - are we still good for Q2 2013 for scripting? 4. The relative ease with which scripts can be recorded/replayed is good. It compares well to other tools on the market on this score. 5. Parameterization is supported in a variety of input formats including databases. 6. Correlation is managed by regular expressions that you specify in the editor. It takes a few tries to get this right, especially if it's been a while since you last wrote POSIX-compliant regexps. 7. There is support to monitor server machines of most types. 8. Currently only HTTP/S is supported ( with parameterizable NTLM authentication credentials). So Citrix, Client/Server is out of scope for now. If the tool moves from a black-box design to a more open extensible design, people like us could extend this tool to do work across more protocols. The last conversation I had with the product folks, I said exactly the same thing - that is, you can't fully anticipate what features the users will want and respond at that speed. Instead make the tool extensible and let the users "roll their own" on the platform. 9. The Controller/Generator setup is similar to that of Loadrunner. Same ports etc. 10. Nomenclature differs from LoadRunner. Read "Test" as LoadRunner "Scenario" Read "Scenario" as LR "Script" Read "Station" as LR "Generator" Cheers Suresh2.5KViews2likes0CommentsSolution: McAfee On-Access Protection/Scanner interferes in Results Analysis from Generators
I have McAfee Virus protection software running on my load controller and generators. This includes the McAfee On-Access Protection and On-Access Scanner. Apparently LoadComplete's TCP communication from Controller to Generators and vice-versa is snagged by McAfee. This would result in post-run result analysis taking anything from 2 to 4 hours to complete. Needless to say, the Task Manager showed McShield.exe taking up to 50% of processor utilization on these machines. Turning off the On-Access Protection and On-Access Scanner from the VirusScan Console application resulted in immediate collation of results. See attached image for details.4.7KViews0likes1CommentRe: Solution: Transaction response times in LoadComplete
Here's the code for LogMessage.php <html> <head> <title>Log Message HTTP POST Handler</title> <head> <?php // This PHP is for logging any runtime messages to the database //$StationName = $_REQUEST['FromStation']; ?> </head> <body bgcolor="#FFFFFF" text="#000000"> <p> <?php $VUserID = $_REQUEST['VUserID']; $ActionNeeded = $_REQUEST['TxAction']; $Message = $_REQUEST['LogMessage']; $con = mysql_connect("localhost", "root", ""); // or die('Error', mysql_error()); if (!$con) { die('Could not connect: ' . mysql_error()); } mysql_select_db("LoadCompleteTx"); $query="INSERT INTO `loadcompletetx`.`runlog` (`VUserID`, `TxAction`,`LogMessage`, `TimeIn`) VALUES ('$VUserID', '$ActionNeeded', '$Message', CURRENT_TIMESTAMP);"; if(!mysql_query($query, $con)) { die ('Error updating database'); } else { print("<p>Success: Logged"); } mysql_close($con); ?> <p> </body> </html>3.4KViews0likes0CommentsRe: Solution: Transaction response times in LoadComplete
Well, I tried to to attach code, but the forum won't let me do it. Here's the relevant snippets: This is the GetVUserID.php file <html> <head> <title>HTTP Post Handler</title> <head> <?php //$StationName = $_REQUEST['FromStation']; //print("Testing"); ?> </head> <body bgcolor="#FFFFFF" text="#000000"> <p> <?php function gen_uuid($len=8) { $hex = md5("yourSaltHere" . uniqid("", true)); $pack = pack('H*', $hex); $tmp = base64_encode($pack); $uid = preg_replace("#(*UTF8)[^A-Za-z0-9]#", "", strtoupper($tmp)); $len = max(4, min(128, $len)); while (strlen($uid) < $len) $uid .= gen_uuid(22); return substr($uid, 0, $len); } $ActionNeeded = $_REQUEST['TxAction']; If ($ActionNeeded = "GetVUserID") { $a = gen_uuid(8); print("User ID:$a<br>"); } $con = mysql_connect("localhost", "root", ""); // or die('Error', mysql_error()); if (!$con) { die('Could not connect: ' . mysql_error()); } mysql_select_db("LoadCompleteTx"); $query="INSERT INTO `loadcompletetx`.`runlog` (`VUserID`, `TxAction`, `TimeIn`) VALUES ('$a', '$ActionNeeded', CURRENT_TIMESTAMP);"; /* print("<p>"); print("Running query: $query"); print("<p>"); */ if(!mysql_query($query, $con)) { die ('Error updating database'); } else { print("<p>Success: Logged"); } mysql_close($con); ?> <p> </body> </html>3.4KViews1like0Comments- 3.4KViews1like0Comments
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.6.4KViews0likes5Comments