Page History

...

Blueriq Studio is a client-server application where the data is stored in a SQL Compact Edition database (.sdf file in /Studio/Repository). For optimal user experience and modelling speed, data is cached in memory. The data consists out of the repositories, branches, projects, modules, version management and global configuration settings.

How does the cache work?

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 (like a decoupled architectureas discussed in A maintainable and agile architecture and in DCM Foundation - v4 [editor]) and the system configuration will keep Studio performance optimal.

...

Because there are a lot of variables it is not possible to give a general advice which applies to all environments but at the moment our largest customers have a .sdf file that is around 800MB which results in to a maximum of 10GB of memory used. Alternatively, if the teams are developing on completely different and isolated projects it should be considered to setup multiple Studio servers so each team has its own Studio environment.

...

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.

Reloading configuration

Via the development dashboard, a user is able to press the reload configuration button. This button restarts the entire Blueriq Runtime. All user sessions are destroyed, all Solutions are removed, the database connections are destroyed and the Blueriq Runtime restarts. During the reload, users are unable work with the Blueriq Runtime. Although it could be useful to use this function, application servers like Tomcat, JBoss or Websphere are not always able to clear the memory correctly so it is advisable to restart the application server instead of using the reload configuration function.

Advice on sizing

From our experience a single Blueriq Runtime could accommodate 10 active modellers business engineers in a development Blueriq modelling environment running on 4GB of memory. When developing modelling with more active developers business engineers 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.