Page History

...

When a user opens a branch for the first time, the data of that specific branch is cached in memory. Depending on the size of the branch, this could take some time but after that, reads and writes will happen in the cache and stored in the database. The branch will be evicted from the cache 30 minutes after the last user interaction with the cache.

Memory allocation

Depending The amount of memory that is needed depends on the number of users, repositories, branches, branching strategy, size of the projects and the size of the .sdf file a . A general rule of thumb is that Studio allocates a maximum 12 times the size of the .sdf file in memory. For example, a database of 10MB on disk will take up to 120MB in memory. A well-chosen branching strategy, the functional architecture (as discussed in A maintainable and agile architecture and in DCM Foundation) and the system configuration will keep Studio performance optimal.

...

As stated, a Solution in memory is only removed once all the user sessions are disconnected. In a production environment this happens over time and typically there are not a lot of Solutions running on one single node. But, in a development environment, when developing with a lot of users that press the reload project(s) button this can quickly increase the memory allocation which could lead results in a performance decrease.

Via the development dashboard there is an easy solution to solve this problem. Select Widgets and then select the Sessions widget. This widget shows a list of your active user sessions per branch. Here you are able to can close specific or all user sessions or close them all at once.

Advice on sizing

From our experience a single Runtime could accommodate 10 active modellers in a development environment running on 4GB of memory. When developing with more active developers it’s possible to increase the size of the memory but keep in mind that a restart of the servers will then take longer because the JVM needs to evict the allocated memory. Alternatively, if the teams are developing on completely different and isolated projects it should be considered to setup multiple Runtime environments so each team has its own Runtime environment and size it accordingly.

...