Error -26000: Not enough memory (12942648 bytes) for a new escaped bufferin LrwUtilSubmitDataBody::MakeAdditionalRoomForOK.
ratna kumari
We upload images to the system using this application.
We have 3 scripts-
6 images of size 3MB
9 images of size 4MB
Initially we had 20 images of size 4MB but we reduced as per the hp recommendation to 9 images because of load runner limitation.
Using the above 3 scripts,We have exectued 75 users test for image uploading in performance center and it was fine.
But when we executed the same for 100 users we got 1 error regarding memory.
Below is the error message.
Error -26000: Not enough memory (12942648 bytes) for a new escaped bufferin LrwUtilSubmitDataBody::MakeAdditionalRoomForOK.
Initially we tried for 130 users and we got many memory errors due to which we have reduced the number of users to 75.
http://support.openview.hp.com/selfsolve/document/ KM195419
Below is the suggestion given by hp people.
1. Take 2 copies of the old scripts.
2. In the 1st copy change mode to URL mode and select those 2 options and add the 2 steps mentioned in the document.We need to regenerate the script ,
but as we discussed we may have to do correlation again.I thought to suggest to replay the script instead of regenerating it,
but i think we have to regenerate it.
3. In the 2nd copy without chaninging to URL mode try adding the 2 steps as mentioned in document and regenerate/ replay the script.
James Pulley
I suspect you have run out of RAM on your load generator. Rebalance your load across n+1 generators.
James Pulley
--
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
1)Declare the following statement in your script:
web_set_sockets_option("UPLOAD_CHUNK_SIZE","8192");
The above function limits the upload chunk size to 8192 bytes. This is a recommended value for large file upload transactions.
On the contrary if your scripts are downloading large files from the server then you should restrict the upload chuck size at the server side as well. (example - Assuming the http server is WebLogic, the configuration should look something like this: set JAVA_PROPERTIES=%JAVA_PROPERTIES% -Dweblogic.Chunksize=8192 -Dweblogic.utils.io.chunkpoolsize=8192.).
2)Increase your load generator machine's virtual memory.
3)User perfmon and monitor your LoadGenerator machine's resources during load tests.
-Chaitanya M Bhatt
http://www.performancecompetence.com
--
ratna kumari
rajeshnaidu kurumati
Virtual Machine 1
Operating System : Windows XP
MS Office : Office 2007
Processors : Dual Core
Physical RAM : 3 GB
HDD : 250 GB
thanks and regards,
rajesh.
James Pulley
with controller) is far from optimal for a test environment. A minimum
number of matched hosts would be four
1. Controller
2. Primary Load Generators
1. Control Generator
Ideally your test bed would have seven
1. Controller
1. Control Generator
1. Hot Spare
4 Primary Load Generators
Your average LR sale is still ~ 100K. To fully populate seven hardware
matched Load Generators, even if you pulled them off the shelf from your
local Wal-Mart would be 3.5K You will burn at least that much in
direct and indirect project costs trying to recover from poor tests due
to constrained load generation.
At the minimum, decouple your generator from your controller. Your
controller is very video busy. The interrupts for video have to be
addressed immediately and requires stealing cycles from the CPU that can
otherwise go to applications (such as virtual users). For your load
generation hosts, install them with "blank" screen savers and run them
as such.
To your core question, how many per host? That is a very difficult
question because the resource weight of a virtual user is determined at
least as much by your development methods as your protocol selection.
Topgear has a somewhat humorous take on this whole issue of efficiency
on the driver (developer) versus car (virtual user) versus location
(load generator host) argument. It can be accessed here,
http://www.youtube.com/watch?v=dKTOyiKLARk
James Pulley
http://www.loadrunnerbythehour.com/testexecution
James Pulley
not ___Virtual Machines___. There is a well known issue associated
with the virtualization of the system clock on virtual machines which
causes the virtual machine clock to become unsynchronized with the
physical clock. Periodically this results in the two clocks having to
be resync'ed, which will invariably cause a jump in the clock when this
happens. And yes, it does happen while timing record transactions are
open. This happens with all software virtual machine vendors.
Hardware partitioned systems are unaffected.
This leaves the integrity of your timing records with a problem,
particularly since you do not have a physical reference control factor
which can be used to measure skew in your virtual machines. Your
current form of test bed has problems in the following areas:
* Initial conditions - You will never be able to guarantee the same
level of influence from other VM hosts on your load
generators/controllers at the beginning, during or end of tests. No
documented, controlled initial conditions? Then it is not a test, it's
art (just run it......)
* Reproducibility. Because of the highly variant nature of your test
bed your ability to reproduce a test precisely is compromised. Who is
to say that during test one which showed horrible performance that two
or three other virtual machines were not engaging in both heavy disk and
and network activity which distorted the amount of CPU, disk and network
bandwidth available to your test environment. Test two may not show
these issues when re-run without any environmental changes.
Reproducibility is at the core of calling something a test. If you
cannot reproduce, then it cannot be called a test.
* Control factors. This is exactly as described. It is a reference
incorporated within your test which allows you to measure the integrity
of your tests and your test results. It is not possible to incorporate
a control generator on VM technology.
In the end, you want to appear as a rational scientists examining the
requirements and reporting the results. One with solid processes,
practices and results which are highly defensible, accepted by
development and project management with few issues involving "kill the
messenger." Your current model instead provides any member of any team
that wants to dispute your results with an aluminum baseball bat which
which they may attack your results, or attack you! As an industry we
do not want this, because test integrity issues are as corrosive to your
group directly as they are to the industry, particularly when developers
and project managers move from one project to the next, one company to
the next. A couple of bad experiences and some of these parties will
simply dismiss the results being returned, assign a low value to the
discipline and the tools.
Compensation follows perceived and actual value: Time to reverse the
trend.
James Pulley
http://www.loadrunnerbythehour.com
On Sat, 2010-07-10 at 10:35 -0400, James Pulley wrote:
> You have several issues in play. A single generator (assuming combined
> with controller) is far from optimal for a test environment. A minimum
> number of matched hosts would be fourrajeshnaidurajeshnaidu
> 1. Controller
> 2. Primary Load Generators
> 1. Control Generator
> rajeshnaidu