SAP GUI User

[Ltester]

For SAP GUI, processes based users, we can not use 1000 of users on
load generators because they are not using threads like web users

How many users running SAP GUI(Processor based) can i run on a Load
Generator machine that has 3GB of Memory and its Intel Duo 3.3 MHZ

if there is an equation to measure this, please provide

Thanks

[James Pulley]

There is no formula. Everyone's virtual users vary in their resource
demands on Disk, CPU, Memory and Network. Turn on Full logging and you
might get 10 very slow users. Have large variable declarations that run
100's of MB and you might get ten as well.

Follow guidelines for including a reference or control generator with only a
single user of each type on the host. Make sure your hosts are matched and
include at least three load generators, none of which are the controller
(two primary load plus one for the control/reference set). When you
execute your test watch the response times for your control group versus
your global group. If you have an application induced response time issue
then you will observe that both your control group and your global groups
response times will rise indicating an application bottleneck. If you have
a load generator induced bottleneck which is slowing your virtual users then
you will observe your global group performance decaying but your control (or
reference group) continuing at a similar rate of performance or perhaps
improving slightly because of the removal of the load caused by your global
group vusers slowing.

Be conservative in your approach for number of users. You don't want to
introduce a test-bed based performance problem for your virtual users.
Heck, just go purchase a full set of generators. Considering the cost of
failure of an SAP implementation plus the cost or performance testing,
purchasing a matched set of seven computers for user as generators is a
pittance compared to the delays in testing and the increased risk associated
with using generators of unknown quality borrowed from other organizations.
Why seven? One controller, One control/reference generator, One hot
spare/parts cannibal, Four primary load. Industry stats are still that one
in seven computers will fail within the next 18 months, hence the hot
spare/parts cannibal. Murphy is most likely to strike right in the middle
of your short turnaround testing efforts where your ability to get a quick
turnaround on parts/replacement is close to nil.

--
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(www.performancecompetence.com)]

This is a highly debatable topic I must say. It is very subjective.
Memory foot print which HP as a vendor provides is not very accurate.
The impact of Memory and CPU footprint of any protocol on a
Loadgenerator also depends greatly on the length of the business flow
and on the workload profile which the client expects the system to
achieve. Example: Hypothetically, if in a SAP GUI application if you
have 100 virtual users just entering employee name and number in a
field and submitting it to the server and are iterating it only 2
times in a half hour period(which if is your test duration) then I
would say you may not need more than 1 load generator which is sized
with 3Gb of RAM and 3.3 Ghz dual core Intel processor.

Straight from the vendor, the memory footprint of SAP GUI is ~4mb per
mdrv process. To estimate the CPU utilization for SAP GUI protocol, I
would recommend you record few CPU counters of your LoadGenerator
through 'perfmon' while deriving baseline result and multiply the
metrics with the target Vu count your expected to achieve.

It is ideally recommended to have as many boxes as possible to match
the theoretical requirement, but as we all know, one of the many usual
enemy for a performance tester is lack of sufficient loadgenerator
machines. Hence for the benefit of time and to avoid further pestering
from your boss to somehow resolve the issue - try utilizing your
loadgenerator boxes as efficiently as possible by:
1. Logging only when error occurs.
2. Precisely calculating think-time between transactions which helps
by exerting less load on the load generators too(note this point as
very important!).
3. Uninstalling any daemon applications running on Loadgenerators
which is not a part of AUT.
4. Avoiding excessively using the "Show Vuser" option during test
execution.
5. Declaration of variables with large size should be avoided, which
directly helps in conserving overall memory. Consult the development
team if your unable to estimate the right size(This is a major concern
in Java Vuser and VB Vuser scripts).
6. Never over-iterate a script.

Chaitanya M Bhatt
Email: chaitan...@performancecompetence.com
Web Link: http://www.performancecompetence.com

[prasenjit dutta]

hi all,

i have not work on SAP application. So I just wanted to know that, is it like that SAP application cannot be run on thread based like web users and have to run on process based?? or it is like that if the application is recorded with SAP protocol then only have to run in process based??

Thanks,
Prasenjit

--
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

--
Prasenjit

[Floris Kraak]

On Mon, Nov 23, 2009 at 11:22 AM, Chaitanya
Bhatt(www.performancecompetence.com) <bhatt.c...@gmail.com>
wrote:

> This is a highly debatable topic I must say. It is very subjective.

> ...

> try utilizing your loadgenerator boxes as efficiently as possible by:

> ...

> 2. Precisely calculating think-time between transactions which helps
> by exerting less load on the load generators too(note this point as
> very important!).

Hmm .. what do you mean with "precisely calculating"? You mean trying
to make the think times match what a real user does? Or something
else? And how does this contrast with the requirement to not make all
users use exactly the same thinktimes constantly? (by setting up a
random percentage deviation in the runtime settings, of course.)

> 6. Never over-iterate a script.

I don't know what you mean with this. Over-iterate?

Regards,
Floris
---
'What does it mean to say that one is 48% slower? That's like saying
that a squirrel is 48% juicier than an orange - maybe it's true, but
anybody who puts the two in a blender to compare them is kind of
sick.'
--- Linus Torvalds

[John Crunk]

Overiterate? Doesn't this depend on how many cycles you want to produce?

Bet I lost most of you now:)

John Crunk Ph.D ABD
Sent from my iPhone

[Floris Kraak]

On Mon, Nov 23, 2009 at 8:46 PM, John Crunk <jcr...@comcast.net> wrote:
> Overiterate? Doesn't this depend on how many cycles you want to produce?
>
> Bet I lost most of you now:)
>

Not really.
Cycles of what, though? ;-)

[John Crunk]

Sure it does. It is machine cycles

John Crunk Ph.D ABD
Sent from my iPhone

[chaitanya bhatt]

Hi Floris Kraak / John Crunk

 

Good question. I know, I left a few things hanging in there, because I didn't have time to go about explaining it in detail.

 

What I meant by calculation of think time is: Sometimes clients give tons of web analytics reports to the Performance Engineering team to derive the workload of their application system. In such situations, where you do not have workload profile directly given to you, instead you are burdened with those overwhelming statistics from the web analytics reports, you tend to give a fixed think-time of 5 seconds throughout the application out of laziness and complacency, instead of sitting down and working like an end user at least once with a stop clock in hand to calculate the actual time needed by a 'human' user to fill in all the fields in a particular screen. Example: If it is a screen with 40 fields where the real end user refers a fax sheet to get information to fill those 40 fields, he obviously can't fill it within 5 seconds, he might take at least 2-3 minutes.

 

Over-iterating = Exceeding the expected number of iteration of a particular workflow during the test execution. (This happens a lot when people calculate wrong pacing values and have scenario executed in "Run for duration" mode)

Regads,

Chaitanya bhatt.

 

[Floris Kraak]

On Mon, Nov 23, 2009 at 9:02 PM, John Crunk <jcr...@comcast.net> wrote:
> Sure it does. It is machine cycles
>

Iterations can also be thought of as 'cycles' though ;-)

[chaitanya bhatt]

Sure, it can be termed as cycles.

[Floris Kraak]

On Tue, Nov 24, 2009 at 3:35 AM, chaitanya bhatt
<bhatt.c...@gmail.com> wrote:
>
> you tend to give a fixed think-time of 5 seconds throughout the application out
> of laziness and complacency, instead of sitting down and working like an end
> user at least once with a stop clock in hand to calculate the actual time
> needed by a 'human' user to fill in all the fields in a particular screen.

That's a typical case of 'engage brain please' engineering. It really
depends on a number of factors, like what your end users base is. It
typically does not consist of highly specialised loadtest engineers
;-)

I agree using a stopwatch is better than just blindly using a fixed
thinktime, but that still has it's limitations. On the other hand,
using fixed thinktimes has value sometimes too; If there is little or
no session management for instance it doesn't matter too much as long
as the transaction numbers are correct.

Personally I prefer to attempt hitting specific target transaction
numbers (measured from production, if available) with a target session
length. Then the exact think times don't matter too much as long as
they're somewhat sane, at least (so no 5 seconds delay between complex
forms! :-) )
you don't always have those numbers, though.

> Over-iterating = Exceeding the expected number of iteration of a particular
> workflow during the test execution. (This happens a lot when people
> calculate wrong pacing values and have scenario executed in "Run for
> duration" mode)

As long as you keep your eye on the targets for numbers of
transactions per second for the various parts of your scenario there's
nothing wrong with iterating as many times as you like, imho.
I've seen long running scenarios (65 hour weekend tests) find some
pretty subtle resource leaks, so in fact I highly recommend it.

[chaitanya bhatt]

Well said, I agree on your statement - Floris Kraak.

 

The idiosyncrasies of load testing experience is such that it always revolves around certain conditions and situations a load tester is has faced.

 

That's why I mentioned this topic as highly debatable. We can go on and on with each and every member of the group posting different aspects of performance testing and arguing eternally, but as long as we all religiously follow the quintessentials of load testing mentioned below no one can go wrong.

 

1. Know what the SLA states.

2. Understand the real user usage patterns.

3. Know how to load the server.

4. Know how much to the load server.

5. Know what type of load needs to be induced on the AUT.

6. Know your test tool well to maximize on its capabilities.

7. Know your test environment.

 

Regards,

Chaitanya M Bhatt

Email: chaitanya.bhatt@ performancecompetence.com

Website: http://www.performancecompetence.com

 

[Floris Kraak]

On Tue, Nov 24, 2009 at 10:03 AM, chaitanya bhatt
<bhatt.c...@gmail.com> wrote:
>
> 7. Know your test environment.
>

Interesting you should mention that one, we found a bottleneck in an
'invisible' network component just yesterday.
With 'invisible' I mean "none of the infrastructure charts I have
mention it's existence and everyone else seemed to have forgotten,
too"

It's pretty hard to pinpoint problems in a network component you don't
know about, I tell you ;-)

[chaitanya bhatt]

this shows quintessentials of PT are generic. :)

so what was this invisible component? (just outa curiosity..)

[Floris Kraak]

On Tue, Nov 24, 2009 at 3:28 PM, chaitanya bhatt
<bhatt.c...@gmail.com> wrote:
> this shows quintessentials of PT are generic. :)
> so what was this invisible component? (just outa curiosity..)
>

A load balancer that was already removed from the chain in production
9 months ago because it caused performance issues. They added it
-after- our previous test of course so it wasn't present in the
previous test either ;-)

Ah well, such is life.
Luckily that wasn't the only thing ..

[chaitanya bhatt]

lol...so true..

[prasenjit dutta]

but will anyone answer my question, what I asked earlier????

--
Prasenjit