The online community for software testing & quality assurance professionals
 
 
Calendar   Today's Topics
Sponsors:
Lost Password?

Home
BetaSoft
Blogs
Jobs
Training
News
Links
Downloads



Testing Tools >> HP / Mercury LoadRunner

Pages: 1
chris.ballard
Junior Member


Reged: 02/18/02
Posts: 1
LoadRunner vs WinRunner
      #107347 - 02/26/02 08:58 AM

Hi,

My company is considering using Loadrunner to do some performance analysis on some client-server applications. We would like to measure the performance of our apps under different load conditions - e.g. different number of users, additional records in system, processes occuring at the same time on the server, that kind of thing.

I'm sure that we could use WinRunner to perform some basic testing to measure the time taken to return records from a query etc. Can anyone tell me what advantages there are to using Loadrunner over WinRunner and what additional features it has? Are there any add-ons or pre-written modules that could be used in WinRunner to perform basic load/performance testing?

Many thanks!

------------------


Post Extras: Print Post   Remind Me!   Notify Moderator  
James PulleyModerator
Moderator


Reged: 08/01/01
Posts: 5551
Loc: NC
Re: LoadRunner vs WinRunner
      #107348 - 02/26/02 09:48 AM

Chris,

I think a positioning of Mercury's product line is in order here. This should roughly parallel the Mercury sales presentation. Let's say your company needs to answer some questions, which tool will fit?

"Will this application work for one person?"
This is primarily a question that WinRunner automated tests, combined with manual tests will answer. The results of the tests are often stored in TestDirector as a repository to manage the testing process and report on progress.

"Will this application scale to my expected load and beyond?"
This is the primary focus of LoadRunner. To complicate matters further, LoadRunner supports two primary types of users. They are a GUI Virtual User (which actually takes advantage of a WinRunner script driving the application) and an API Virtual User. The second type is often referred to as a database virtual user, even though these API types of users could be Web, Sockets, a middleware interface, Java, even MAPI. The primary advantage of the API type of user of the GUI user is the ability to load many more "users" on a box for the generation of load -- It's amazing how small an application can become once you strip the GUI and a fair amount of application processing out of it.

"Why would I run both GUI and API virtual users?"
Consider a client server application like a birthday cake. The topmost layer, the frosting, represents the GUI. Users blow out candles, they press 'OK' buttons. The second layer down, consider this the application processing layer. Depending upon whether the application is "thin" or "thick" this might be visuall represented as either a wafer thin layer of chocolate ganache spread across the cake or a deep dark german rum soaked..... Well, you get the idea. The third layer down is the communication layer/Application protocol layer -- we'll call this layer 'red velvet cake. Once again, this layer could be fairly complex, some of the Java/Corba and COM/DCOM interfaces come to mind. Or, it could be relatively thin, such as running a terminal interface that resides barely above the sockets layer. The goal of running with the virtual users types for a similar transaction is to guage the weight of the GUI and the application processing layers of the client/cake. I have been part of a team that uncovered a GUI performance issue that resulted in high-speed video cards being purchased for a group of users, becuase it was cheaper to buy the cards, support them and deploy the application, than it was to re-engineer the application for better performance. For reference purposes, in the above analogy, the frosting and application procesing layers would classically be represented as the Application Layer in the OSI Model. The Communication Layer would be represented as the Presentation layer of the OSI Model.

So, while you can see that the two products have a seperate engineered focus, the decision to use WinRunner versus LoadRunner is not necessarily a mutually exclusive one because of the issue of the GUI Virtual user. We could even carry the questions forward to "How will I monitor this application for performance after it is deployed?" This would take us into the product definition of Topaz or even TAPM (Tivoli Application Performance Manager), which makes use of Mercury technology for performance sampling.

I hope this helps to clear up some confusion. If you have a chance to observe a Mercury sales presentation (I know, then you have to deal with all those "when are you gonna make a purchasing decision" sales calls) the role of each product should become clearer.

Happy Testing.....

------------------
James Pulley
nospam.jpulley@nospam.itestsolutions.com
iTest Solutions, Inc
704-243-2854 (voice)


Post Extras: Print Post   Remind Me!   Notify Moderator  
JakeBrake
Moderator


Reged: 12/19/00
Posts: 15290
Loc: St. Louis - Year 2025
Re: LoadRunner vs WinRunner
      #107349 - 02/28/02 12:59 AM

quote:
Originally posted by chris.ballard:
Hi,

My company is considering using Loadrunner to do some performance analysis on some client-server applications. We would like to measure the performance of our apps under different load conditions - e.g. different number of users, additional records in system, processes occuring at the same time on the server, that kind of thing.

I'm sure that we could use WinRunner to perform some basic testing to measure the time taken to return records from a query etc. Can anyone tell me what advantages there are to using Loadrunner over WinRunner and what additional features it has? Are there any add-ons or pre-written modules that could be used in WinRunner to perform basic load/performance testing?

Many thanks!


The post by James Pulley is well-stated. Additionally and in reference to your above questions:

WinRunner can measure performance. The functions start/end_transaction provide that for you. However, unlike LoadRunner - you would have to manually compile/correlate the measurement results from the test result file where the transaction times are written.
Also, pre-written modules per se, do not exist.

Usage example: I have generated loads using LoadRunner while having a single WRun-based GUI user measuring performance also. I used WinRunner more as a monitoring tool to watch for specific insidious stuff that happened at random on the client. It paid off in this instance.

------------------
JP

[This message has been edited by jpensyl (edited 02-27-2002).]

Post Extras: Print Post   Remind Me!   Notify Moderator  
Pages: 1



Extra information
0 registered and 29 anonymous users are browsing this forum.

Moderator:  AJ, James Pulley, ptrussell_nc, JimHowell1970 

Print Topic

Forum Permissions
      You cannot start new topics
      You cannot reply to topics
      HTML is disabled
      UBBCode is enabled

Rating:
Topic views: 4666

Rate this topic

Jump to

Contact Us | Privacy statement SQAForums

Powered by UBB.threads™ 6.5.5