Developing with Blueriq Studio and Runtime

When working with Blueriq in a development environment there are a few topics that are important to know when the number of users or applications increases.The following paragraphs describes the inner workings of the Blueriq Studio and Blueriq Runtime.  

Studio

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

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 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 - v4 [editor]) and the system configuration will keep Studio performance optimal.

Branching strategy

When modelling in Studio there are 3 common strategies:

Trunk only

Using this strategy every user works the same single branch. Because there is only one branch the size of the allocated memory is limited.

Feature branches

Using this strategy every feature is implemented on a newly created branch which, after completion, is merged with the Trunk. As stated, when a user opens a branch for the first time this branch is cached in memory. This means that if there are many users that work at the same time on their own branch, a lot of branches are cached which in turn allocates more memory.

Release branches

Using this strategy every user develops on the development branch and this development branch is copied to a "release" branch and when the application is ready for release it is tagged. The number of branches will be limited and most of the work is done in one single branch which in turn keeps the memory size limited.

Choosing the right strategy depends on the way of working. One small team could easily use Trunk only or the Release branches strategy, while if there are multiple teams working on the same project it could help to introduce Feature branches.

Important note: like any other version management system, feature branches should be deleted after merging with the Trunk to clean up the studio database and release memory.

Advice on sizing

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.

Runtime

Blueriq Runtime is a client-server application which uses 3 datasources to retrieve project exports.

1. Studio datasource; Used for development only, when the Development plugin is enabled. This is when the Runtime is connected to the Studio.
2. Export datasource; Used when a project export .zip file is placed in the Blueriq configuration folder or packaged with the Runtime itself.
3. Publisher datasource; Used when the Publisher Client plugin is enabled.

When the Runtime starts, it will use the different datasources to retrieve the project exports and load them into memory. Depending on the number of exports this will takes some time. For a quicker startup time it is also advised to delete already merged feature branches.

The representation of a project export in the Runtime is called a Solution. Depending on the size of a project export a Solution could allocate up to 50MB of memory (could be more but in our experience 50MB is the maximum we've encountered).

When a user starts an application (via a shortcut or via the development dashboard) a new user session is created and connected to the Solution.

In a development environment, each time a user presses the reload project(s) button, the Runtime determines if there are still active user sessions connected to the Solution. If not, the old Solution is removed and a new Solution is loaded into memory.

If there are active sessions, the old Solution is marked but remains present in memory and the new Solution is loaded into memory next to the old one. New user sessions are connected to the new Solution and when the old Solution has no active sessions, it is removed as well.

The reason for this behavior is that other users that are developing in the Runtime can continue their work.

Note: In a production-like environment (an environment where the Development plugin is disabled) this behavior is the same when a new version of the application is published via the Publisher so that active users do not lose their session.

Clearing memory

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 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 can close specific or all user sessions 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 business engineers in a Blueriq modelling environment running on 4GB of memory. When modelling with more active 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.