SoapUI stuck when several millions data return

Hi aaronpliu,

Sorry for the lengthy post!

Just amalgamating what the other fellas have already mentioned with some extra options (windows config options) that may help. I actually had to do the detail below myself and it did work.

I'd crank up the heap size via the .vmoptions file
I wouldnt bother altering any of the assertions you have as this doesnt use a large amount of resource and try executing the test in headless mode.

Id try running the test immediately after a reboot ensuring nothing extra has been loaded from startup (you can disable a number of things starting up via taskmanager).

Whats the spec of the machine your running this on....does it have at least 16gigs RAM (more likely to work if you have greater than 16gigs RAM) along with an I7 processor?


If getting this working on a slow machine is essential (i.e. theres no option of moving your ReadyAPI! License to a faster machine) then id try the following too.

WINDOWS CONFIG
Have you set your operating system to run on 'best performance'? (Im guessing youre running windows at this point) rather than the 'pretty' option?
Id look at my swapfile settings too....this wont help whilst the focus is on ReadyAPI! but won't hurt and might make a slight difference.

Do you have local admin rights? Id make sure id stop everything "extra" running via your startup (available via taskmanager) touchpad, soundcard, hotkeys, etc. however there are a multitude of startup options that arent available to disable via taskmanager's startup tab and i dont just mean startup folders on your profile as well as startup folder in the registry HKLM/MS/Windows/CurrentVersion/Run. There are tools that will indicate every startup location and youll aee yourself....there are loads of different ways of forcing startup on boot.

If you have admin rights you could look at disabling a number of windows/application services...e.g. you could disable your AV/firewall (which uses a lot of resource) as well as extra stuff... e.g. windows spooler, certain networking options, etc., etc.

I had to do this a while back when i was given a work laptop to use and it was an 8gig/I5 machine and i literally googled all the stuff in my taskmanager that was enabled to startup at boot as well as googling all the difference services that could be disabled....theres more that can be disabled than you think!

Just wondering. You said you have a response returning a lot of records. Im curious whether you can perform the same query via a db interrogation tool. If youre executing a GET in readyAPI! which retrieves 10s of 1000s of records im just wondering how executing the same query via a jdbc SELECT impacts....does this work?

Also. Is there anyway the ReST API you are exercising can be altered to limit the number of records that are returned by adding a 'fetch' or 'limit' or 'top' or 'count' query parameter can be added to the URI to retrieve only a certain number of records? Some APIs ive worked on have had additional query parms added to the API to enable the user to limit the number of records returned (e.g. MS Dynamics CRMs' webAPI supports this). I find it strange that an API would enable the user to retrieve so many records it kills the machine without providing some mechanism to control the number of records returned. How useful would it be to a user to return 10s of 1000s of records to a user? Not very for most scenarios i would guess and it obviously depends on the requirements of the system!

In summary.
If you cant migrate your license to a quick machine, and you cant limit the number of records returned in your API call response, id consider doing the following.

1. Set windows to run on 'best performance'
2. Update your VM/swapfile settings....dont use windows to set swapfile size
3. Minimise the size of your profile. Profiles are always loaded into memory when the machine boots.
Profiles (depending on their size can use up quite a bit of memory, so its worth limiting the size of your logged on profile as much as possible. I.e. delete all temp files and any extraneous stuff that doesnt need to be saved in your profile. Be careful here (use something like ccleaner or equivalent to analyise your profile to id anything that can be deleted)....but delete as much as you can and move anything that csnt be deleted but can be moved out of the profile. For example....you have a desktop, downloads, pictures, videos folders in your profile. Im not saying "repoint your profile to a second drive"...wherever the profile is, it'll still use the same amount of resource (although i always advocate repointing your profile to a second drive anyway), but id empty your profile of all the files in those subdirectories to folders outside your profile.
3. Update .vmoptions file settings ...heap file, etc.
4. Launch taskmanager and view startup. Google the startup options to identify anything that can be stopped starting on bootup and then disable everything you can so it doesnt start at boot
5. Launch the Services control panel applet (its in a parent 'admin' .cpl/.msc...sorry i cant be more specific...im typing this on my phone so cant check at moment) and google all the services listed to identify what they do. Disable every service that isnt essential to run ReadyAPI!, so that the service doesnt launch when the operating system starts. Be careful.....its better to not alter a specific services settings if you dont know what they are, but you can disable a shedload if you do enough research. Theres plenty of webpages listing what the services do and how significant they are.
6. Launch ReadyAPI! and grab the testRunner executable command to execute the relevant test youre talking about and copy it to notepad. Save notepad (but NOT on desktop or in your profile).
7. Restart machine. Open the notepad with the testRunner command and open command window. Paste testRunner command into command window, close notepad, clear the clipboard cache (yes i know, im literally saving mere bytes at this point, but it all adds up, right?)
8. Execute testRunner command!


Thats all i got....hopefully there might be some points in there that might help!

Cheers

Rich