Several BlueMind components use up resources. A typical "per user" calculation cannot be applied because a user who only uses messaging will not generate the same load for the system as a user using messaging and collaborative services (Calendar, etc.) and a smartphone.
As a result, sizing is calculated "per unit", on the following basis:
Also, for a same amount of units, a use of messaging only won't consume the same amount of resources as a messaging+collaborative use: unlike collaborative tools, messaging, for example, is more heavily dependent on IO than on CPU.
CPU is stated in number of cores. Reference values are based on recent Xeon-type CPU.
BlueMind has several services, as a result we recommend a minimum of 2 cores.
Please note that too much CPU can lead to other issues on virtualized environments (https://techan.fr/problemes-de-performance-sur-vmware-du-a-du-cpu-ready.html)
*With the Cyrus service and bm-elasticsearch on dedicated servers
Storage / IO Performance
The messaging service is a heavy user of IO, as a result storage is sized in IOPS . As for storage space, it depends on client requirements (quotas, etc.)
IOPS per unit
Performances minimales des disques
Le stockage est dimensionné en IOPS, un service de messagerie étant un gros consommateur d’IO. L’espace de stockage est lui directement dépendant de la demande du client (quotas,..)
Selon l'usage final, tous les disques n'ont pas nécessairement besoin d'avoir le même niveau de performance. Voici les IOPS minimum pour toute installation :
Pour les installations supérieures à 2000 utilisateurs, les iops attendus peuvent être calculés selon le nombre d'utilisateurs et l'usage :
IOPS data for storage devices (wikipedia)
Core/RAM distribution over several servers (virtual or otherwise) is not described here.
However, for up to 16/24 cores, we believe that a single-platform installation makes sense.
Above this threshold, and to manage populations of tens of thousands of users or more, the architecture must be distributed.
Also, the messaging part as well as the database (which collaborative use/smartphone places heavy demands on) must be kept separate from the rest.
Bandwidth requirements cannot be predicted as they largely depend on mail traffic.Please note that the data on bandwidth usage of the BlueMind calendar and smartphones below clearly shows the preponderance of mail traffic.
BlueMind Calendar bandwidth
For a user with the Calendar application open in their web browser, in http and in bytes (measured on the network with Wireshark):
Client to server: 215 bytes/sec (1,067+5,388)/30
Server to client: 56 bytes/sec (293+1,398)/30
With room for maneuver, for 1,000 Calendars running in web browsers:
For a user with the Contacts application running in their browser, in http and in bytes:
By doubling the value measured to ensure a comfortable safety margin, we calculate a bandwidth of 288 bytes per second for a user who has launched the Contacts application.
Microsoft provides the following ActiveSync ratios: 1.04KB/s/user
i.e. for 100 smartphones: 104Kbit, or 13KB/s
By taking a sensible safety margin of x2, we calculate: