Issues with capturing large data from server by using Web_reg_save_param

[Prasad Y]

Hi Group -

I am having larger value from server which i need to cpature by using
Web_reg_save_param.

I added this fucntion web_set_max_html_param_len("1024") to increase
size..but this is max limit right?

I think because of larger size of my server o/p, i am not able to
capture the o/p....is there any way that i can increase more size than
1024 bytes?

Please suggest -

Thanks

[James Pulley]

Yes, you can alter the size of your capture up to (2^32-OS RAM
Usage-Application RAM Usage). You will kill your VUGEN and LOADGEN machine
by setting a value that high, horribly crippling it from supporting more
than one (and potentially less than one) users, but nothing prevents you
from doing so. We expect our application developers to be conservative in
their use of memory and to release back to the pool when done with use in
order to ensure scalability - we should follow the same practices in our own
development of virtual users.

Lead by example.

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

[franklin inbaraj]

Hi James,

 

we are using web_set_max_html_param_len("3000") in our testing. will this affect VUGEN or LOAD Generators? if yes, let me know what is the max value we can use, which will not make any impact on VUGEN and Load Generators.

 

Regards,

Franklin Inbaraj

[James Pulley]

The max value you can use is 2^32 (4GB) less the amount of RAM in use by current applications and operating systems.   You can use so much RAM that you can get only a single user to run on your load generators successfully.

 

I will turn the question back around to you.   Do you need ~3K per variable or will 2K suffice?   Will 1.5K do the job?   We ping developers hard on their use of RAM, being aggressive in its use and not cleaning up after themselves and how this impacts the scalability of a solution as RAM is exhausted.   We should follow the same edicts ourselves as script developers, use enough resource to be effective but not be promiscuous.

 

I do not know how many users you will run on a load generator.   I do not know how many variable assignments will be impacted by your param length definition.   I do not know the configuration of your load generators.    I don't need to know these things:  What I do know is that if your load generator hardware is all matched and you follow best practices for including at least three load generators with one of them being a control generator running on a single virtual user of each type, you will be able to discern immediately if your load test environment is becoming a bottleneck to your test as opposed to your application becoming a bottleneck to your test.  

 

How will I know?   Easy.   When your test definition is the bottleneck and your load generators are overloaded you will have your global population slowing while your control group continues at the same or faster pace.   If your application slows then both your control group and your global group will slow at the same time.

---

From: lr-loa...@googlegroups.com [mailto:lr-loa...@googlegroups.com] On Behalf Of franklin inbaraj
Sent: Thursday, December 17, 2009 11:02 AM
To: lr-loa...@googlegroups.com
Subject: Re: Issues with capturing large data from server by using Web_reg_save_param

--

[franklin inbaraj]

thanks James for your valuable explanation. Really its going to help me in future tests.

 

Ragards,

Franklin Inbaraj

[Floris Kraak]

On Thu, Dec 17, 2009 at 5:21 PM, James Pulley
<jpu...@itestsolutions.com> wrote:
> The max value you can use is 2^32 (4GB) less the amount of RAM in use by
> current applications and operating systems.   You can use so much RAM that
> you can get only a single user to run on your load generators successfully.
>

It also depends on how many _other_ parameters you're trying to save,
doesn't it?
You'll need some memory for that at least.
Honestly I suspect the practical limit is a bit lower than this, but
it's kind of irrelevant. If you need more than 100kb for correlating a
single value I really would question the quality of the application
under test ;-)

> I will turn the question back around to you.   Do you need ~3K per variable
> or will 2K suffice?   Will 1.5K do the job?   We ping developers hard on
> their use of RAM, being aggressive in its use and not cleaning up after
> themselves and how this impacts the scalability of a solution as RAM is
> exhausted.   We should follow the same edicts ourselves as script
> developers, use enough resource to be effective but not be promiscuous.

On the other hand, there are limits to how much effort one can invest
in keeping the runtime overhead of your script down. This is pretty
much like setting requirements for the application under test itself.
If you know you'll never need to run 1000 vusers optimising it just to
get to 10.000 on a single box is just overkill ;-)

> What I do know is that if your load
> generator hardware is all matched and you follow best practices for
> including at least three load generators with one of them being a control
> generator running on a single virtual user of each type, you will be able to
> discern immediately if your load test environment is becoming a bottleneck
> to your test as opposed to your application becoming a bottleneck to your
> test.

In some circumstances this may be a little

>
> How will I know?   Easy.   When your test definition is the bottleneck and
> your load generators are overloaded you will have your global population
> slowing while your control group continues at the same or faster pace.   If
> your application slows then both your control group and your global group
> will slow at the same time.

There is another way: Run a single user against a completely different
application that is 'known to be good'.
It's not as foolproof as the method outlined above but it will catch a
lot of things without requiring 3 generators.

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

[chaitanya bhatt]

Do not blindly set a  variable size. Print the parameter to the log file(lr_output_message) and compare the parameter length captured during replay against your recorded value and check if your parameter is truncated after being captured. If you observe a dramatic difference in its length then increase the parameter capacity.

Saying  "...I think my output value is large..." is not good. Always be certain about the cause of the problem. Ignoring the fact and defining variable sizes according to ones own whims and fancies can cause unforeseen problems during load test execution.

Chaitanya M Bhatt
Website: http://www.performancecompetence.com

--