Working with Big Repositories in Tosca
Find a some useful tips in working with your repository
Situation / Introduction
Tosca works fine and allows laziness in building up the test repository as long as it does not reach a certain size and keeps nice and small. But after years of working and many people involved, it will happen that the repository is that big, that almost everything will take a lot of time.
The following guidelines shall help to avoid running in such a situation and make you able to still be productive when your repository became huge.
Workspaces and the local Filesystem
Not every action you can take to improve your working quality with Tosca has to be done in Tosca directly. Tosca is of course also relying on your physical hardware and network setup. Here are some improvements that can be made on your local setup.
Keep your Workspace local, not on a Network Share
Keeping your workspace on a network share can have a drastical performance decrease, because every interaction from Tosca with your local repository database will result in a network operation. This happens often, because Tosca reloads objects from its local database all the time. If you have a Solid State Disc (SSD) and a normal hard disc, put your workspaces and Tosca installation there if possible. SSDs are way faster in accessing data.
Real time virus scans
Exclude the Tosca installation directory and the workspaces from the real time virus scanner. It can slow down the local data base access.
Do not create Copies of your Workspaces in the Windows File System
When you would like to have multiple workspaces, do not copy a workspace within the Windows file system. If checking out or setting up a new workspace takes too long, use the Clone Util to create a valid duplicate. (find more information in our Webhelp under: Creating and Managing Workspaces> Cloning workspaces or click here for the direct link to Tosca 9.2 manual)
Using Tosca and Multiuser Workspaces the right Way
(Related articles can be found in our online help in the chapter: Managing Projects> Multiuser mode> Synchronization. Direct Link to Tosca 9.0 )
To keep the local repository in sync with the common repository, Tosca transfers data between those two. This synchronization is triggered by many different tasks in the Tosca Commander as for example Update All, CheckIn All, Checkout… All of these tasks consider the amount of objects that have to be synchronized. That means the more objects the local workspace repository has, the more expensive and time consuming it will be to run any of those tasks. Therefor the goal for the local workspace shall be: Keep it as small as possible. The following mechanisms will improve the performance of the local workspace.
- Include & Exclude from Synchronization
The tasks include and exclude from synchronization provide the easiest way to reduce the amount of objects that get considered during synchronization tasks with the common repository.
Every object that is excluded from synchronization will not be taken into consideration when the repositories get synchronized. It is highly recommended that everything that is needed rarely will be excluded. The excluded state of objects is only for the local workspace, other users with other workspaces can have different objects excluded. Every object can be back included into the synchronization at any time.
- Synchronization Policies
Synchronization policies give the opportunity to exclude objects per “default”. The policy is a change on an object or the whole tree and will be committed in the common repository. Those objects are then per default excluded for the workspaces. Every workspace can still include those objects back into synchronization at any time. Another advantage of this mechanism is that those objects will not even be synchronized in the initial workspace creation. That means the more objects are excluded this way the smaller the newly created workspace will be. The different policy options can be looked up from the link above.
- Compact Workspace
The Compact Workspace task recreates the local workspace repository. It is a cleanup task and should be run as often as possible. It has the biggest impact if run after many objects have been deleted or excluded. It shrinks the local repository file thereby saves space on the local hard disk and improves the object access times in the database.
- Slim Workspace
The slim workspace concept was introduced with Tosca version 8.1.2. The option slim workspace can be selected when creating a new workspace. A slim workspace is a workspace that has everything excluded from synchronization per default. With this mechanism it is possible to create a small workspace, even from a large common repository without excluding everything with synchronization policies. After creating the slim workspace, the user can then include the objects he needs.
- Lost Objects & Missing References
Lost objects are objects that do not have a superpart and are not included in the object tree anymore. For further details see: https://support.tricentis.com/community/article.do?number=KB0011316
In most cases, lost objects are unwittingly generated by using Individual CheckIns or Revoke CheckOuts. As a best practice it is highly recommended not to use this tasks. Always go for the safe approach and use a CheckInAll. An often seen scenario is that something has to be quickly fixed and not everything that is changed shall be checked in, then an individual check in is used to do so. As a best practice recommendation, a 2nd workspace should be used to perform the small change with a regular CheckInAll. This will not affect the changes in the other workspace.
Missing references can occur, when objects are deleted, but have for example a reference to an excluded object. When the excluded object gets included again, it misses the deleted object, because the change was not performed on it. The task "Purge missing references" can be used to get rid of them.
Additional Tosca KnowHow:
- Reuse Everything instead of copying Stuff
One of the most important things in Tosca is the concept of reusing objects. Whether it is a Module that gets reused in many Testcases, a reusable Teststepblock within a library that gets referenced many times or any other object that can be reused. It always saves performance when objects get referenced instead of copied. The memory consumption is lower, the overall performance is better and the maintenance of the repository will be much handier.
- Virtual Folders and Big Queries
Virtual Folders are a nice way to filter objects for a certain criteria. But if they contain complex TQL-Queries that will take a while to execute, it can disturb a user from working. The Query will get executed when the perspectives get refreshed. This will be done at least after all tasks that communicate with the common repository. To prevent this behavior, only show the virtual folder results in the details view when necessary and close it when not.
- Requirements and Coverage specified
The coverage specified of Requirements is a value that has to be calculated and can consume some time to do so. This will also be done when the perspective gets refreshed. It is possible to toggle with F11 if the coverage specified shall be shown or not.
Maintaining the Common Repository
Common repositories will get big after years of working with them. This may become a problem when database backups start taking a lot of time and disc resources. Additionally, the larger the common repository gets, the harder it is to take care that the local workspaces still stay small.
A big topic in executing Testcases is to generate logs that proof the execution and give the information that everything works as expected. Usually the amount of execution logs is fast growing and thus will consume a lot of disc space. Tosca provides several mechanisms to deal with this problem.
- Compressed Logs
In earlier Tosca versions, Tosca created an own object for every log. This behavior led to the creation of many objects, depending on the granularity of the log level (Testcase, Teststep, Teststepvalue). Compressed logs provide an alternative saving option, by combining all Teststep and Teststepvalue logs to a compressed Testcase log. This compressed TestCaselog is a XML structure with all the needed information in it. Instead of saving every log object in the common repository, a compressed XML will be saved for every Testcase. The more granular the log level was set, the better will be the result of the compressed logs, compared to the normal ones. With Tosca 8.4 the compressed logs will be generated by default and cannot be disabled anymore. A drawback is that reports that work on normal log objects have to be altered to deal with compressed logs.
- Archive Logs
Old actual logs can be archived to keep their results, but reduce the space they need. Logs that get archived will be compressed and excluded from the synchronization by default.
- Object Versioning
Tosca provides the possibility to track the changes in the common repository. The full functionality is documented in our online manuals in chapter Managing Projects> Object versioning (direct link to Tosca 9.2 manuals)
- The downside of this feature is that the common repository will be approximately twice as big as without versioning and the CheckInAll is slightly slower. If the feature really is not needed, it is recommended to turn it off (only possible for Tosca Versions 10.3 and lower).
- Files in Repositories
A big topic is how to handle big files within Tosca (Videos, Images …). Tosca provides the possibility to embed files. This functionality should be used for small files, usually text files. If the files get larger it is recommended to reference them as LinkedManagedExternal in a managed file area. The related article can be found in our online manuals in the chapter: Working with Tosca> Referencing or embedding files> Referencing files and managing files externally (Direct link to Tosca 9.2)
- Rearrange indices in your Common Repository
During the lifetime of a repository, millions of objects will be created, removed and altered in the common repository. Rearranging the Indices allows your database to remap all entries and speed up the searches for an object. We are providing a SQL-Script for MS SQL Server in order to do this. It can be found in the installation folder of Tosca.
Out of Memory Exceptions, What can be done to prevent them?
Windows has its limitations on how much RAM can be used by a single process. On 32 Bit operating systems it is not possible to allocate more than 2GB of ram within a single process. 64 Bit operating systems allow more to allocate. Tosca of course has the same limitations. In big workspaces with lots of objects it is possible to reach this limit quite fast when loading many objects. The following points shall give an idea how to prevent it.
- Optimizing TQL Queries
Most of the times when an out of memory exception gets thrown, a TQL-Query is the trigger for it. This happens because huge amounts of objects can get loaded to perform a search on them. Some optimizations can and should be made, to perform queries faster. Try to avoid starting searches on the project root, always go down to a specific object if possible. Always restrict searches to specific types. E.G: =>SUBPARTS:TestCase[Name == “Testcase1”]”. Only use the “=>” operator if necessary. Searches can be split in multiple smaller ones that can be restricted to a type, instead of performing one big search on everything. If not all results at once are needed, the keyword “->SUBSET(<TQL Search>, <Number of Results>) can be used.
- Clearing the loaded Objects and releasing Ram
Sometimes it is necessary to free the loaded objects. This might be the case if 2 big TQL Queries have to be executed after each other and the first one already uses so much ram and loads so many objects that an out of memory exception happens during the 2nd one. As a workaround, every task that synchronizes with the common repository (Update All, CheckIn All …) unloads the local objects and releases ram.