Board Server: What's new in 7.4

Installing Board Server 7.4

To install Board Server version 7.4, run the setup.exe program. It is necessary to uninstall any prior versions of Board Server before running the setup program.

 

IMPORTANT !!  Board Server 7.4 is a 64-bit program only, the 32-bit version of Board Server does not exist for version 7.4. It is necessary to have a valid 64-bit Board license to use version 7.4

 

Board Server 7.4 has the following hardware and software prerequisites

- Operating system must be a 64-bit system: Microsoft Windows 2008 R2 (64-bit edition), Microsoft Vista Professional (64-bit edition), Microsoft Windows 7 (64-bit edition).

- Microsoft .Net Framework 3.5 and Microsoft .Net Framework 4.0 and ADOMD.Net

- RAM: minimal amount of RAM depends on the size of the Board database(s) used but in comparison to version 7.3 the minimal  requirements are now significantly higher. Generally a Board database will occupy an amount of RAM which can be 1.5 to 3 times more than the size of the database on disk (in HBMP format) in case the option full in-Memory is used. When the Hybrid configuration is chosen, then the amount of RAM necessary is more limited since only the data dictionary (entities, members, cube definitions and bitmaps) are loaded in memory. As a rule of thumb, you may consider three typical RAM requirements:

- small server: 8 to 16 GB of RAM for small databases. These are generally databases that in version 7.3 are below 1GB in disk size and in B7.4 are below 500MB.

- medium server: 16 to 32GB of RAM for mid size databases. These generally are databases that in version 7.3 have a size between 10 to 30GB and once converted range between 2 to 4GB.

- large server: 32 to 64 GB of RAM for large databases. These databases could have a size of 50 to over 100GB in version 7.3 and after conversion range between 5 and 20GB.

 

Note that the number of concurrent users also affects RAM utilisation however only in a very limited manner. For example, if a database takes 5 GB of RAM when fully loaded in memory (single user), then if the server is accesses by 30 or even 50 users simultaneously the RAM consumption will generally increase to no more than 1 or 2 GB to a total of 6GB or 7GB.

 

In order to server a high number of concurrent users, your server must have multiple CPU cores. As a rule of thumb you may consider the following as references:

- small server: a system generally serving 5 to 50 concurrent users, for a standard Business Intelligence application should have no less than a CPU hexa-core or two quad-core CPUs.

- medium server: a system generally serving 100 concurrent users, for a standard Business Intelligence application or 20 to 40 concurrent users working on a simple planning application should have two to four CPUs hexa-core for a total of 12 to 24 cores.

- large server: a system generally serving several hundred concurrent users on a standard Business Intelligence application or 50+ concurrent users working on a planning application should have no less than four CPUs hexa-core, but this dimensioning may vary depending on the frequency of utilisation or the complexity of the processing involved in the simulation or planning solution.

 

The above guidelines are rough estimates based on average cases. It is possible and sometimes necessary to make a more accurate dimensioning of hardware requirements by running some a workload tests with a Board database and Capsules that represent the complexity and nature of the solution to deploy.

 

Configuring Board Server 7.4

The Board Server program has one additional tab which allows to configure the new settings for the HBMP engine.

 

Board_Server_Config_InMemory_Hybrid.jpg

 

Database Mode

- In-Memory: loads all the database in RAM: the data dictionary, entities, entity members, relationships, the bitmaps (cube addressing structures) and the cube data.

- Hybrid: loads all the database in RAM: the data dictionary, entities, entity members, relationships and the bitmaps but not the cube data, leaving it by default on disk.

 

If the full In-Memory option is chosen, all the data of a database is loaded in memory, this will result in an amount of RAM used greater than the size of the database on disk.

 

Hybrid should be chosen when the in-memory option is not viable because the memory required is too high. This option reduces RAM consumption and grants huge scalability because the amount of RAM needed for a loading in memory a database will depend on the multidimensional space mapping and is no longer proportional to the amount of measures or transactions loaded. Though this option can save a huge amount of memory and grant scalability as no other in-memory technique can, it affects performance only by 15% to 20% because most of the query processing is anyhow performed in-memory (all the computation of what data to fetch and where) and requires a disk access only at the very end of the process chain.

Moreover the Hybrid mode allows still allows to selectively define per each single Board cube (in-RAM) if it should be managed fully In-Memory or not, therefore the cubes which are more frequently used can be configured fully in-memory for best performance, while the lesser used cubes can be left on disk and will be loaded only on demand when required by a query.

 

NOTE !!

For planning applications or in general solutions providing user data-entry and execution of procedures, the In-Memory mode should be preferred, however if not possible due to RAM constraints, use the Hybrid mode but set all cubes on which users perform data-entry or run procedures to be in-RAM.

 

Max number of databases to keep in memory

This parameter defines the maximum number of databases that the Board Server may keep simultaneously open therefore in memory (even with the Hybrid configuration opening a database implies loading parts of it in memory). A database is loaded in memory the first time a query or request on that database is received (for example when a user opens a Capsule using the database). The database is never unloaded unless the service is stopped or the Board administrator manually unloads it.

On a production server, this parameter should be set equal or greater to the number of Board databases residing on this server but it should also be verified that the server capacity is sufficient to open all the databases.

 

Multi-core layout processing

Tick this check-box to enable parallel processing of multiple blocks of a single Layout. This setting should generally always be switched on, unless the server has limited CPU resources available. Disabling the parallel processing of Layouts will reduce performance of single user queries (Layouts) and may improve overall throughput in case of concurrency but only when in case the server CPUs are saturated. If the server CPU capacity is sufficient (CPUs don't fully saturate to 100%) then parallel processing of Layout grants better performance for the individual user and in high concurrency situations.

 

Multi-core on loading cubes

This option should always be switched on, unless you need to perform a test for tracing the amount of RAM used for loading into memory entities, cubes, sparse structure etc.. To perform a test:

- stop the Board Server service,

- disable this option, set the In-Memory or Hybrid mode as desired and then restart the service,

- open the database to analyse from the BoardClient.

This action will trigger the loading in memory of the database. When completed, a log file named HBMP_DatabaseName_InMemory.Log is created in the directory Board\Dataset\Log. Open the log file with a text to editor.

At the end of the test remember to switch this option back on.