Out of memory error.
I am using load UI and got an Out of memory error. I dont know what this was caused by. Is it likely to be the limitations of my PC? The test appeared to keep running although no more results were ...
Forum Discussion
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.
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.