Out of memory error.

I've sent my project - hope you can help.

Sorry to press you - but I could really do with some help on this. I can't understand the reason for this message.
Thanks

The message 'Unable to start java virtual machine' is because your 32-bit Java installation cannot handle more than a certain amount of memory -- this is normal.

I got your project and we will have a look at it tomorrow (got back from eastern holidays today)!

/Henrik
eviware.com

Hi Andy!

I've done some testing now with loadUI 1.0.x and I can confirm that your project behaves weird with very high loads. I also found that it seems to be working better when using the Fixed Rate Generator instead of the Fixed Load. Also, don't set Max Internal Threads to more than you need since loadUI won't necessarily reuse threads until it has to.

That being said... In your loadUI project, one TestCase was set to a fixed load of 5000 (that is 5000 simultaneous requests) for 11 minutes. This is an extremely high load (for example, Google handles ~34k searches/s. Each search takes about 0.15 seconds, giving 34k*0.15 = 5100 simultaneous requests -- and Google's got more than a million of servers).

The good news is that I also tried to run your project with 5000 simultaneous requests in loadUI 1.5 (internal build) local mode without any problems. Distributed to agents, I could multiply that number easily.



Regards!

/Henrik
eviware.com

Ok, thanks for that information. When will there be a version of the new LOADUI available?

I realise that the load is large but I'm testing individual services and I need to understand the limits of the software (not that this will necessarily be anything like real life) but just so we have the limits for the record as a benchmark.

However I think it's fair to say that we don't at this point quite understand the relationships between the services in the wider system and how a single user interaction could spawn any number of requests to various service endpoints. So in this respect 5000 may not necessarily be a huge number, we just don't know at this point.

We obviously want to be in a position where we can say we have headroom for further expansion for years to come as more customers come on board and this is why it might seem like our numbers are large.

How is this type of testing done on enterprise level systems - where testers want to understand the limits of the system but appreciate that this is nothing like a real system simulation.?

Consider the situation where a request might take 10ms (these numbers are purely hypothetical but may well be possible for just benchmark testing of a service which just returns a response) even at maximum rate using the fixed load generator ie 1ms interval, the maximum load that can be achieved is 10. Basically I can only have a load less than or equal to the response time of the request in ms using this generator.

I think what is needed is for the fixed load generator to genuinely be that; (ie you can put whatever load you like and it will ramp up) rather than applying a ceiling to the load which is what it seems to do at the moment using the interval as the barometer. Kind of a combo of fixed rate and fixed load so that you can spawn more than 1/ms if necessary to get to the desired load but also limit the load as in the fixed load generator at the same time.

Then again the software I'm testing may well fail well before I hit the problems I've experienced with LOADUI thus far. Time will tell. I can always distribute to agents of course.

In another post I've asked about running tests from the command line. I've used property transfer to utilise the same soapui test and just read in different endpoints - what I need to understand is if these tests will be executed at the same time or if the second line will only execute after the 1st has finished running (Which might be a test that takes 10mins). (The latter would be preferable ;-))

If you have any views please let me know.

Hi,

The first beta of loadUI 1.5 will be released by the end of May, and we're showing off some of the new features in the live webinar tomorrow.

The Interval setting of the FixedLoad component isn't really intended to be a ramp-up feature, more a sanity check limit if you need to limit the interval at which requests are being sent. Setting this to 0 will ensure that loadUI will attempt to run as many concurrent requests as you have configured the load, failing either due to client limitations (memory, network, cpu) or server limitations.

For the scenario you've described, I think a better approach than using the Fixed Load Generator would be to use one of the rate-varying Generators (like the Ramp Generator). Going by request rate instead of concurrent load often gives a more realistic simulation, as the figures you get (our service can handle X requests per second while keeping the SLA) can be compared to actual log files, etc. It's important to note that 5000 concurrent requests in no way represents 5000 users, unless all 5000 users are actually trying to attack the server.

Either way, if the client is the bottleneck, then the solution should be distribution using agents.

As for your other question, I think my colleague has answered that in the other thread.

Regards,
Dain
eviware.com