LoadRunner v11 - Ajax TruClient - Tips and Tricks
nyairh
to help you make the most of the new Ajax TruClient protocol available
in LoadRunner v11.
Ajax TruClient is a new advanced protocol for modern JavaScript-based
applications, including Ajax.
The protocol emulates user activity within a Web browser. Scripts are
developed interactively in Mozilla Firefox.
The tips and tricks document is available at:
http://support.openview.hp.com/selfsolve/document/KM1017957/binary/LoadRunner11.00_AjaxTruClient_TipsTricks.pdf.
Please send your feedback directly to me or to lt_cust_...@hp.com
Yair Horovitz
Functional Architect, Load Testing and ALM
HP Software
Email: yair.h...@hp.com
WebTestGadfly
mean, how many VUs can you support this way?
WTG
On Nov 9, 4:55 am, nyairh <nya...@gmail.com> wrote:
> Just wanted to let you know we've published a tips and tricks document
> to help you make the most of the new AjaxTruClientprotocol available
> in LoadRunner v11.
>
> The protocol emulates user activity within a Web browser. Scripts are
> developed interactively in Mozilla Firefox.
>
>
> Please send your feedback directly to me or to lt_cust_feedb...@hp.com
> Yair Horovitz
> Functional Architect, Load Testing and ALM
> HP Software
James Pulley
system resources. Think potentially tens of megabytes (or greater!) per
virtual user. You also get a hit on the CPU. Network hit, nominal, as the
same data flows occur if you are using WinSock, HTTP or AJAX style users.
You could potentially turn your disk subsystem into a thrash to death
bottleneck if you don't have enough ram to support your users. Consider 64
bit generators as the default for this type of virtual user (with lots of
RAM). Because of the high resource dependency it would be advisable not to
place agents between your virtual users and your resources, as would be the
case with a Hypervisor and virtualization.
Best solution, try and up your skills to be able to handle as much as
possible with a straight http virtual user. Developers will always be able
to build a toolkit to defeat such tools and the market will always be able
to engineer a less effective person with the label "performunz testur" who
will be unable to use a tool effectively no matter how low the skill level
needed to be effective. But, with the skills to use a lower level
interface you get the benefits of a lower resource use virtual user model
(more per VU host) and the skills to fill in the gap when new toolkits
emerge from the development ether
James Pulley, http://www.loadrunnerbythehour.com/PricingMatrix
WTG
--
You received this message because you are subscribed to the Google
"LoadRunner" group.
To post to this group, send email to LR-Loa...@googlegroups.com
To unsubscribe from this group, send email to
LR-LoadRunne...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/LR-LoadRunner?hl=en
chaitanya bhatt
If your load test scenario has small number of users, then go for TruClient, but if your test scenario has more than 400-500 Vus - then I suggest you should make use of one of the transport level scripting protocols in LR.
Chaitanya M Bhatt
http://www.performancecompetence.com
Venkat P
From the HP Tips and Tricks Document as circulated by Yair Horovitz earlier in this group (And others)
-Venkat
WebTestGadfly
one.
So if I have an XP/SP3 box with a 2-core CPU and 3 GBytes of RAM, you
are suggesting that one can run 6-8 TruClients, at which you run out
of both available RAM and CPU %.
Is that pretty much correct?
-WTG
On Dec 5, 8:40 pm, Venkat P <vjpj...@gmail.com> wrote:
> *"The amount of Ajax TruClient Vusers that can run on a single load
> parameters. Internal HP benchmarks indicate that for various applications
> under test, a single Ajax TruClient Vuser can utilize around 60-120MB of
> memory (footprint) and consumes 3-30% of single CPU core.""
> From the HP Tips and Tricks Document as circulated by Yair Horovitz earlier
> in this group (And others)
>
> -Venkat
>
> On Sun, Dec 5, 2010 at 10:13 PM, chaitanya bhatt
>
>
> > In one of webinars with HP, they claimed it support 50Vu per LG(3GB Ram,
> > Intel 3.33GHz). I don't have any link for you to cite this and so I suggest
> > you cross verify this info.
>
> > If your load test scenario has small number of users, then go for
> > TruClient, but if your test scenario has more than 400-500 Vus - then I
> > suggest you should make use of one of the transport level scripting
> > protocols in LR.
>
> > Chaitanya M Bhatt
> >http://www.performancecompetence.com
>
>
> >> Anybody know anything about scalabilty of the TruClient protocol? I
> >> mean, how many VUs can you support this way?
>
> >> WTG
>
> >> On Nov 9, 4:55 am, nyairh <nya...@gmail.com> wrote:
> >> > Just wanted to let you know we've published a tips and tricks document
> >> > to help you make the most of the new AjaxTruClientprotocol available
> >> > in LoadRunner v11.
>
> >> > AjaxTruClientis a new advanced protocol for modern JavaScript-based
> >> > applications, including Ajax.
> >> > The protocol emulates user activity within a Web browser. Scripts are
> >> > developed interactively in Mozilla Firefox.
>
> >> > The tips and tricks document is available at:
> >>http://support.openview.hp.com/selfsolve/document/KM1017957/binary/Lo....
>
> >> > Please send your feedback directly to me or to lt_cust_feedb...@hp.com
>
> >> > Yair Horovitz
> >> > Functional Architect, Load Testing and ALM
> >> > HP Software
> >> > Email: yair.horov...@hp.com
>
> >> --
> >> You received this message because you are subscribed to the Google
> >> "LoadRunner" group.
> >> To post to this group, send email to LR-Loa...@googlegroups.com
> >> To unsubscribe from this group, send email to
> >>http://groups.google.com/group/LR-LoadRunner?hl=en
>
> > --
> > You received this message because you are subscribed to the Google
> > "LoadRunner" group.
> > To post to this group, send email to LR-Loa...@googlegroups.com
> > To unsubscribe from this group, send email to
>
> - Show quoted text -
Venkat P
The same question keeps getting asked about other protocols as well - Web HTTP, Web HTML, Ajax C and S . The consumption of resources would be dependent on the compexity of these scripts - whether a simple login -click through - log out or some really complex stuff emulating true real users.
Now if you take the ranges given by HP and assume that the lower end means simple Scripts and the higher range limit are those of typical complex Scripts and applying your dual core and 3 GB RAM limitations - you will note that Ram becomes the limiting factor when the script is simple - so you will probably do 51-52 Users (@60MB/User). And if the script is complex and resource hungry - your CPU is the limit and you will end up with 6 Users with the protocol. So anywhere between 6-52 is your answer.
cheers
Venkat
WebTestGadfly
And the
"your mileage will vary" admonition is accepted. The insight is
appreciated.
But, doesn't anyone have any direct experience to share? Are there
any case studies
or specific validation experiments that meet scientific
reproducibility criteria?
-WTG
On Dec 6, 11:24 am, Venkat P <vjpj...@gmail.com> wrote:
> The best answer would be "YMMV - Your Mileage May Vary".
>
> The same question keeps getting asked about other protocols as well - Web
> HTTP, Web HTML, Ajax C and S . The consumption of resources would be
> dependent on the compexity of these scripts - whether a simple login -click
> through - log out or some really complex stuff emulating true real users.
>
> Now if you take the ranges given by HP and assume that the lower end means
> simple Scripts and the higher range limit are those of typical complex
> Scripts and applying your dual core and 3 GB RAM limitations - you will
> note that Ram becomes the limiting factor when the script is simple - so you
> will probably do 51-52 Users (@60MB/User). And if the script is complex and
> resource hungry - your CPU is the limit and you will end up with 6 Users
> with the protocol. So anywhere between 6-52 is your answer.
>
> cheers
>
> Venkat
>
Venkat P
To add a bit more info on the memory footage - the following is what Yair posted on the LinkedIn forum
Regarding memory footprint, it's important to understand the Ajax TruClient is a UI level protocol and does not work at the transport level, unlike the regular web HTTP Vuser. Therefore, the memory consumption of a Ajax TruClient Vuser includes a browser instance, DOM and Javascript. These consume memory and vary per application.
HP's benchmark included several applications using different Ajax libraries.
However each customer application is individual and Vusers should be bench-marked and sized before testing, to arrive at realistic footprint numbers for the application under test.
-Venkat
Shane (HP)
This is an absolute understatement, attempting to discredit the
capabilities of the tool. I would recommend anywhere between 50 and
250 vusers per LG depending on memory footprint of the individual
users. Most likely you will fall somewhere in between. But dont take
my word for it. Test it yourself.
Run 10 users and measure the footprint.
Hope that helps,
Shane Evans
On Dec 6, 11:39 am, WebTestGadfly <webtestgad...@gmail.com> wrote:
> You seem to be saying, then, between 6 and 52 TruClient type users.
> And the
> "your mileage will vary" admonition is accepted. The insight is
> appreciated.
>
> But, doesn't anyone have any direct experience to share? Are there
> any case studies
> or specific validation experiments that meet scientific
> reproducibility criteria?
Venkat P
James Pulley
On Friday, February 8, 2013 3:29:15 PM UTC-5, Magnus Jensen wrote:
I wonder, is it possible to script (in either c or java) inside a vuser recorded script to controll/manipulate elements, clicking radio-buttons and so forth on a web app/page using Ajax and being under test?
Problem is that when running a vuser script against a web app implemented using Ajax I need to manipulate page elements in order to get the script running (using http-protocol) and because http-protocol is focused on recording http-traffic as in web requests and responses the manipulation/client side behavior is not captured during recording.
James Pulley
GUI Virtual User Scripts are written in QTP and operate the end user interface just as a user. So, if you need absolute manipulation of the end user interface as a user, then this is your route. Alternae? Citrix or RDP but forget the rich object information available with QTP GUI Virtual Users
From: LR-Loa...@googlegroups.com [mailto:LR-Loa...@googlegroups.com] On Behalf Of Magnus Jensen
Sent: Friday, February 08, 2013 6:26 PM
To: LR-Loa...@googlegroups.com
Subject: Re: LoadRunner v11 - Ajax TruClient - Tips and Tricks
Hello James,
Recording a VUser (GUI) script against my asyncrone webapp misses to capture some 'Actions' as in clicking and choosing i.e. a radiobutton. This is because there is no reguest/respons traffic happening (using http protoco in LRl).
Question being could this be done manually, as in putting some custom JavaScript into the recorded script, at the right step, to manipulate (read: "clicking and choosing i.e. a radiobutton") the webpage/app before the next web_submit/urlis to be executed?
I hope you understand my description :-)
Thank you for being helpful with your experience!
//Magnus
--
You received this message because you are subscribed to the Google Groups "LoadRunner" group.
To unsubscribe from this group and stop receiving emails from it, send an email to LR-LoadRunne...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
James Pulley
So long as the actions use HTTP as a carrier protocol, even if asynchronous the actions will be captured. The nature of true Asynchronous applications is that they have some component of Fire and forget while a thread waits for a response and the order of the actions can be different next time through, even for the same business process.
Here is what I have found….Business processes tend to be stepwise and synchronous in nature. Where asynchronous elements do exist are for calls to external components independent of the business process under test (in the case of a commercial or business facing application, social media|etc… excluded). These apps record just fine, especially since the calls to the third party components which are not under consideration for test are going to be scrubbed anyway when you execute.
From: LR-Loa...@googlegroups.com [mailto:LR-Loa...@googlegroups.com] On Behalf Of Magnus Jensen
Sent: Friday, February 08, 2013 6:42 PM
To: LR-Loa...@googlegroups.com
Subject: Re: LoadRunner v11 - Ajax TruClient - Tips and Tricks
This being an asyncrone app, some actions do not get captured by regular recording due to that LR http-protocol only captures http-traffic (req/respond):
My question being: Is it possible to add some custom code to manipulate the page under test during tests-run to get the right state before calling the next 'recorded' step?
Thanks you for your replies on LR so far.
Best Regards
Magnus
On Friday, February 8, 2013 11:35:58 PM UTC+1, James Pulley wrote:
--
James Pulley
I have never found an absolute need to use TruClient where I could not handle the application with traditional technologies. In many cases TruClient is being deployed to address a paucity in actual user skills to address dynamic data in standard application. In short, one end of the balloon animal is being squeezed and the resource consumption is being moved elsewhere. There are certainly places where the applications are so complex and dynamic where what is handled by TruClient provides an efficiency boost over standard HTTP only development models. I have not run into them. I have colleagues who have and claim benefits from TruClient in such a case.
From: LR-Loa...@googlegroups.com [mailto:LR-Loa...@googlegroups.com] On Behalf Of Magnus Jensen
Sent: Friday, February 08, 2013 7:18 PM
To: LR-Loa...@googlegroups.com
Cc: james....@jamespulley.com
Subject: Re: LoadRunner v11 - Ajax TruClient - Tips and Tricks
But as you have allready stated in some other posts I have red; keep the script at a http-Level do not include i.e. TruClient in Your testware. I will og for that.
James Pulley
TruClient != QTP
Quicktest Professional is an automated functional testing tool which is used to drive the actual end user interface of the application. A single OS instance and full instance of the application under test are required for this virtual user type.
From: LR-Loa...@googlegroups.com [mailto:LR-Loa...@googlegroups.com] On Behalf Of Magnus Jensen
Sent: Friday, February 08, 2013 7:27 PM
To: LR-Loa...@googlegroups.com
Cc: james....@jamespulley.com
Subject: Re: LoadRunner v11 - Ajax TruClient - Tips and Tricks
just to clarify. TruClient is QTP?
it does not matter to this question, but it is ineresting if that is the case (all being HP)...