Forum Discussion

austino's avatar
austino
Contributor
9 years ago
Solved

SoapNG Crashes Running All Test Suites At Project Level

Version: Ready! API 1.4.1

Windows 7

core i7

8-16GB

 

My team has been using SoapUI since 4.6, and recently upgraded to Ready! API 1.4.1. We all have noticed on different machines that running large projects in SoapNG eventually start causing the program to become very slow to respond, and eventually the application itself will become fully unresponsive and we have to force quit. When this happens, the CPU stays around 80% and 1.7GB of memory. This is running on computers with core i7's and 8 to 16GB of RAM.

 

We also notice that just with general use throughout the day, opening and closing lots of test cases and test suites, performance becomes an issue and a restart of the application is in order to avoid having the application crash.

  • austino's avatar
    austino
    9 years ago

    I changed my .vmoptions file to include these values:

     

    -Xms256m
    -Xmx4096m

     

    and updated my ready-api.bat file with these values:

     

    set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx4096m -XX:MaxPermSize=256m -Dsoapui.properties=soapui.properties

     

    I understand my Xms values conflict in these files, but it appears to have resolved my issue, so I'm just going to leave it.

     

    We use a lot of groovy scripts in our tests, so we believe that could be part of the issue, so if anyone else reading this uses groovy scripts and sees performance issues, make sure you include this piece: -XX:MaxPermSize=256m

     

    I also adjusted a few test case log settings, but I don't think that was the issue because task manager shows that SoapNG is utilizing twice as much memory as before when it would crash (currently it's using 3.8GB of RAM) and it's running just fine after multiple full project runs.

     

    Thanks for offering the link that helped me set the correct memory values.

     

    One more thing to note: if your company has strict group permissions set, you might need to run your file editor as an administrator to be able to edit the values above successfully.

5 Replies

Sort By
    • austino's avatar
      austino
      Contributor
      9 years ago

      I haven't changed any of the default settings regarding java heap size. As for consistency, 2 of our uses have to restart mutiple times a day. During regression test runs, I've had to restart multiple times to complete the run. Some of our test runs touch over 100 test suites and approximately 1000 unique tests, but within those tests I'm calling a lot of other tests I've setup as reusables to help create the proper pre-condition data.

       

      I will look into that article you shared and see if this helps, but I do believe the default settings should be able to handle more situations without resorting to force quitting the application.

      • austino's avatar
        austino
        Contributor
        9 years ago

        I changed my .vmoptions file to include these values:

         

        -Xms256m
        -Xmx4096m

         

        and updated my ready-api.bat file with these values:

         

        set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx4096m -XX:MaxPermSize=256m -Dsoapui.properties=soapui.properties

         

        I understand my Xms values conflict in these files, but it appears to have resolved my issue, so I'm just going to leave it.

         

        We use a lot of groovy scripts in our tests, so we believe that could be part of the issue, so if anyone else reading this uses groovy scripts and sees performance issues, make sure you include this piece: -XX:MaxPermSize=256m

         

        I also adjusted a few test case log settings, but I don't think that was the issue because task manager shows that SoapNG is utilizing twice as much memory as before when it would crash (currently it's using 3.8GB of RAM) and it's running just fine after multiple full project runs.

         

        Thanks for offering the link that helped me set the correct memory values.

         

        One more thing to note: if your company has strict group permissions set, you might need to run your file editor as an administrator to be able to edit the values above successfully.