Recommendations for better sharing performance in large projects

With large Tekla Model Sharing projects with many users, you should take precautions to ensure that sharing works optimally without delays. Here is a list of recommendations and advice that we have collected for model sharing administrators to consider for these types of projects.

Reference Models

Reference models can be really large in file size and slow down reading in and writing out.

• Optimizing their size using an external tool or by adjusting the settings in the originating software will be beneficial also for the model sharing performance. 
• When a reference model is inserted into a shared Tekla model, the reference model is copied to the \DataStorage\ref-folder in the model folder and shared for other model sharing users. There is no need to keep the original reference files in a shared folder. See also Working with reference models in Tekla Model Sharing
• Instead of traditional reference models, consider if Overlay models from a Trimble Connect project would be enough, since they are much faster to handle. See this article for more information about their differences: Should I use reference models or overlay models in Trimble Connect?
• If references are frequently updated, consider limiting how many old versions you keep in your model. Use the advanced option XS_REFERENCE_MODEL_KEEP_VERSIONS_COUNT to set the number of versions.
• Make sure that your references work error-free. If you have problems with the references, they may have become “corrupted” and may need to be Ctrl+Refreshed (a notice of this will be printed in the session history log file). 

Faster read-in times for colleagues in the same office

By setting up a cache server at one of your office locations, you can enhance read-in times for  users within the local network at that office. This ensures that data packets are downloaded from the Internet only once and then shared quickly among users locally, rather than being repeatedly accessed from the cloud by each user. This can be useful even for one user, as interrupted download will automatically continue from where it was left instead of starting over from the beginning.
For more information, see Install the cache service for Tekla Model Sharing 

Local model storage

To ensure good performance, always store the local model folder on a local hard drive. Many people nowadays tend to store their files in cloud services, such as Dropbox, Google Drive, OneDrive etc. This, however, is not recommended for Tekla Model Sharing models, because this will slow down the performance and can cause errors in sharing operations. Local model folders should be located on a local hard drive to guarantee the best performance for Model Sharing. For the same reason, storing the files on a network drive is not recommended.

We have also noticed differences between computers with checksum calculation times. Model sharing calculates checksums when it checks which files have changed. The checksum calculation speed depends on how fast your hard drive can read and write data. Using a faster SSD hard drive can significantly increase the calculation speed. If your computer has a lot of memory, it might store disk cache in the memory to speed things up, potentially bypassing the hard drive. It's a good idea to check what type of hard drive you have to ensure optimal performance.

See also: Using Dropbox as model folder 

Firewall settings

Ask your firewall administrator to check your firewall settings. For example, some firewalls scan zip files both upon receipt and when they are opened, which can create unnecessary delay. 

Location for firm related settings

If your firm or project files are stored on a network drive with a slow connection, it may significantly impact the performance of Tekla Structures. To improve this, consider copying the files locally to your computer.
For more information, see Model sharing and firm folder

Avoid increasing the database size

The model database *.db1 size impacts saving time and also affects model sharing performance. Avoid letting the db1 file grow too big. There is no exact size limit, but there's an increased risk of performance issues when the size is gigabytes. 

Here are some tips to keep the size small:

1. Do not use a copy of an old model as the basis for a new model. Old models that have been used in live projects cannot be completely cleaned. They may contain excess information that increases the size of the model even if you delete all objects and drawings from the model. 
2. Use the Tekla Structures repair commands regularly to keep the model database and library in a good condition: Diagnose and repair the model
3. Make sure that the default values of user-defined attributes are not increasing the model database size. For more information, see the Optimizing Tekla Structures database for user-defined attributes (UDAs) article.
4. Consider where to use custom attributes. They may for example perform complicated calculations at the background which take a lot of time if used with inquire, in the property pane etc. 
5. In some cases the model database might contain obsolete leftover data relating to deleted contour plates and polybeams. When the advanced option XS_DELETE_UNNECESSARY_POLYGONPARTS is set to TRUE, using the Repair model command will help you remove this data from the model database.
6. For more tips, see this article: Tips for large models 

Drawings

Check that you are not storing too many old drawing versions.  Since Tekla Structures 2023 version, write-out no longer automatically cleans up old drawing versions; instead, it retains them based on the advanced option XS_DELETE_UNNECESSARY_DG_FILES. Additionally, there is also the possibility to mark certain versions as Always necessary, which may result in a significantly large number of files accumulating in the drawings folder.

History

The history.db file in Tekla Model Sharing projects stores a detailed record of changes to model objects, including who created or modified them and when, possibly also write out comments and code. History data can be viewed with the Inquire command.

While this historical data is useful for auditing and tracking, it can also grow significantly in size, leading to performance issues. The most effective way to manage the history.db file is to prevent it from growing in the first place; make sure to set this advanced option to FALSE at the beginning of the project: XS_COLLECT_MODEL_HISTORY=FALSE

Removing existing history in a Model Sharing project involves multiple steps and requires collaboration. Detailed methods for deleting history in such projects can be found in the support article: Deleting history in model sharing project

Automating model sharing operations

There are two ways to automate reading in model changes:

• Model Sharing Automation Tool: Keep Tekla Structures running at the end of the day and use this tool to automate the read-in process.
• BIM Publisher Extension: Install this extension to schedule the read-in as a Windows task for a specific time.

Trimble Connect upload

Uploading your Tekla Structures model to a Trimble Connect project can be time-consuming if you do it every time you write out. A more efficient approach is to only upload the model when you create a baseline.

You can change this setting in two ways:

• In newer versions, go to File menu > Trimble Connect > Upload model settings
• In 2024 or older versions, use the advanced option: XS_UPLOAD_SHARED_MODEL_TO_CONNECT=BASELINE

Additionally, you can speed up the upload process by setting the advanced option XS_HIGH_ACCURACY_TRIMBIM_EXPORT=FALSE. This uses a faster, less detailed profile representation instead of a more accurate one.

Modified: 4 Nov 2025