Welcome to the new Parasoft forums! We hope you will enjoy the site and try out some of the new features, like sharing an idea you may have for one of our products or following a category.
Looking for ways to improve SOAtest performance?
Options
LegacyForum
Posts: 1,664 ✭✭
Are you looking for ways to improve the performance of SOAtest? Though the next release of SOAtest will have some performance improvements, I've compiled a "checklist" of things that you can do to improve the performance right off the bat (keeping in mind that the recommended system requirements are: At least 1 GB RAM per processor (2 GB is recommended) ). This is a combination of tips from the best practices guide as well as the user's guide. They are in no particular order:
1) Increase the heap size allocated for SOAtest
This can be accomplished by starting SOAtest with the following additional Java argument: -J-Xmx1024m. For example: soatest.exe -J-Xmx1024m
You can change the value from 1024 to another value. But as an FYI, 32 bit JVMs are limited to ~1.4GB. However, 64 bit JVMs do not have this limitation. Please read the following forum post for more information: http://forums.parasoft.com/index.php?showtopic=437
Note: You can do this without starting soatest from the command line by setting the -J-Xmx argument in the targets section of the shortcut properties.
2) Use a Source Control system as opposed to a Network share drive
Network share drives can sometimes be slower to access than the local file system. We have seen customers who successfully implement that method for a while, but as their assets grow over time, they start to suffer from slower network access—especially when data source or payload files grow quite large, and when users work remotely.
Parasoft strongly recommends the use of a source control system to maintain the test files and keep them in sync for all users. A source control system (such as Subversion, CVS, ClearCase, or many other free and commercial tools) alleviates the problem listed above.
3) Close any .tst files that you're not working on
.tst files that are open in your workspace will be loaded into memory when SOAtest starts up. It is recommended you close the .tst files so SOAtest doesn't consume unnecessary memory. You can tell if a .tst file is open by the + sign next to it. To close an opened .tst file simply double click on it. You can also close a Project folder set which would close any .tst files that belongs to that Project.
4) Split tests into many test suite (.tst) files
Do not lump all your tests into very few .tst files. Having too many tests organized into too few large .tst files could make the product run slower because more tests are open and in memory. Moreover, the benefits of using revision controls in a repository are diminished and remote users over a network could experience slower performance (since they would end up transferring large .tst file sizes instead of smaller ones). SOAtest helps you maintain files into projects and directories to facilitate the management of large numbers of test cases. This results in a more balanced tree of resources that helps you get more out of the organized hierarchy of projects, folders, test suite files, and test suites.
As a side note to better facilitate test organization you can add an extra hierarchy of organization at the .tst file level by adding a general folder. You can do this in the "Navigator" view by right clicking a project and selecting New > Other, then under the "General" folder, select "Folder". You will notice that this folder does not yet show in the "Test Case Explorer" view, that's because it gets filtered unless there is a .tst file in it. So in the "Navigator" view, you can either copy a .tst file into your new general folder or create a new one by right clicking the folder and following the normal prompts, the folder will then show in the Test Case Explorer. This helps you to establish a hierarchy of organization without having to put everything into a .tst file.
5) Leverage SOAtest's ability to utilize external files to reduce the size of your .tst file.
Two main areas where this can be done are in data sources and regression controls. If you are having performance issues that you believe to be memory related, then it is likely not a good decision to use "Table" data sources, which is a data source that is stored inline to the .tst file. In order to reduce .tst file size it would be much better in this case to use something like an excel spreadsheet, which is external to the .tst file. Likewise, if you are having what you believe to be memory related issues and you have regression controls on all of your test responses, it would be wise to use "external" regression controls rather then the default "internal" regression controls. You are given this option when you right click a test suite and click "Create/Update Regression Control". The trade off of doing this is that for each test that you create a regression control, SOAtest creates an external file which it references, so if you have 20 tests that you create regression controls for, your .tst file will be referencing 20 external files. One more way to reduce .tst file size is to NOT save traffic in the traffic viewer if possible, I've seen this make a big difference especially on web functional testing where a very large amount of traffic is possible.
1) Increase the heap size allocated for SOAtest
This can be accomplished by starting SOAtest with the following additional Java argument: -J-Xmx1024m. For example: soatest.exe -J-Xmx1024m
You can change the value from 1024 to another value. But as an FYI, 32 bit JVMs are limited to ~1.4GB. However, 64 bit JVMs do not have this limitation. Please read the following forum post for more information: http://forums.parasoft.com/index.php?showtopic=437
Note: You can do this without starting soatest from the command line by setting the -J-Xmx argument in the targets section of the shortcut properties.
2) Use a Source Control system as opposed to a Network share drive
Network share drives can sometimes be slower to access than the local file system. We have seen customers who successfully implement that method for a while, but as their assets grow over time, they start to suffer from slower network access—especially when data source or payload files grow quite large, and when users work remotely.
Parasoft strongly recommends the use of a source control system to maintain the test files and keep them in sync for all users. A source control system (such as Subversion, CVS, ClearCase, or many other free and commercial tools) alleviates the problem listed above.
3) Close any .tst files that you're not working on
.tst files that are open in your workspace will be loaded into memory when SOAtest starts up. It is recommended you close the .tst files so SOAtest doesn't consume unnecessary memory. You can tell if a .tst file is open by the + sign next to it. To close an opened .tst file simply double click on it. You can also close a Project folder set which would close any .tst files that belongs to that Project.
4) Split tests into many test suite (.tst) files
Do not lump all your tests into very few .tst files. Having too many tests organized into too few large .tst files could make the product run slower because more tests are open and in memory. Moreover, the benefits of using revision controls in a repository are diminished and remote users over a network could experience slower performance (since they would end up transferring large .tst file sizes instead of smaller ones). SOAtest helps you maintain files into projects and directories to facilitate the management of large numbers of test cases. This results in a more balanced tree of resources that helps you get more out of the organized hierarchy of projects, folders, test suite files, and test suites.
As a side note to better facilitate test organization you can add an extra hierarchy of organization at the .tst file level by adding a general folder. You can do this in the "Navigator" view by right clicking a project and selecting New > Other, then under the "General" folder, select "Folder". You will notice that this folder does not yet show in the "Test Case Explorer" view, that's because it gets filtered unless there is a .tst file in it. So in the "Navigator" view, you can either copy a .tst file into your new general folder or create a new one by right clicking the folder and following the normal prompts, the folder will then show in the Test Case Explorer. This helps you to establish a hierarchy of organization without having to put everything into a .tst file.
5) Leverage SOAtest's ability to utilize external files to reduce the size of your .tst file.
Two main areas where this can be done are in data sources and regression controls. If you are having performance issues that you believe to be memory related, then it is likely not a good decision to use "Table" data sources, which is a data source that is stored inline to the .tst file. In order to reduce .tst file size it would be much better in this case to use something like an excel spreadsheet, which is external to the .tst file. Likewise, if you are having what you believe to be memory related issues and you have regression controls on all of your test responses, it would be wise to use "external" regression controls rather then the default "internal" regression controls. You are given this option when you right click a test suite and click "Create/Update Regression Control". The trade off of doing this is that for each test that you create a regression control, SOAtest creates an external file which it references, so if you have 20 tests that you create regression controls for, your .tst file will be referencing 20 external files. One more way to reduce .tst file size is to NOT save traffic in the traffic viewer if possible, I've seen this make a big difference especially on web functional testing where a very large amount of traffic is possible.
Tagged:
0