Forum Discussion
AndyHughes
14 years agoRegular Contributor
Hi Ronald,
LoadUI can do this easily (and much more besides). But in my opinion you need to properly understand what exactly you mean by 140 requests per second. Your test will presumably be run for a certain length of time, during which there will be numerous 'seconds'. (It's not really feasible to run a test for one second.). So you need to look at the stats generated in the table output which is aggregated data for the last 'x' seconds. (I'm not sure if you can get the actual data out for each individual request).
Do you mean 140 complete in 1 second? Under what circumstances? You can send all 140 straight away if you like using the 'burst' functionality on the fixed rate generator. Or just use the same generator to create 140/sec/min whatever. Guess it depends on how your system performs and how long typically these requests take. If they take almost a second each then you will need to have them running concurrently otherwise it will take 140 seconds to complete. (But thats with a fixed load of 1 - which is daft I know). But if they take in the order of milliseconds to complete then a fixed load of 1 isn't so stupid as it will actually complete 140 requests within your allotted second.
Also fixed rate isn't that much different from concurrent users either. (What are those users for, if not to create a situation where there are lots of requests generated per second?). So I'm not really sure how your test number 2 is any different from test 1. It's all just about load on the system.
Presumably the test with 14 per second is supposed to be run for some length of time to simulate normal usage whereas the 140/second will be run for a short time to simulate a spike in usage?
LoadUI can do this easily (and much more besides). But in my opinion you need to properly understand what exactly you mean by 140 requests per second. Your test will presumably be run for a certain length of time, during which there will be numerous 'seconds'. (It's not really feasible to run a test for one second.). So you need to look at the stats generated in the table output which is aggregated data for the last 'x' seconds. (I'm not sure if you can get the actual data out for each individual request).
Do you mean 140 complete in 1 second? Under what circumstances? You can send all 140 straight away if you like using the 'burst' functionality on the fixed rate generator. Or just use the same generator to create 140/sec/min whatever. Guess it depends on how your system performs and how long typically these requests take. If they take almost a second each then you will need to have them running concurrently otherwise it will take 140 seconds to complete. (But thats with a fixed load of 1 - which is daft I know). But if they take in the order of milliseconds to complete then a fixed load of 1 isn't so stupid as it will actually complete 140 requests within your allotted second.
Also fixed rate isn't that much different from concurrent users either. (What are those users for, if not to create a situation where there are lots of requests generated per second?). So I'm not really sure how your test number 2 is any different from test 1. It's all just about load on the system.
Presumably the test with 14 per second is supposed to be run for some length of time to simulate normal usage whereas the 140/second will be run for a short time to simulate a spike in usage?
Related Content
- 2 years agovericomms
- 10 months agojamescollett