About units

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 PDA.

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

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)

RAM

*avec déport du service Cyrus et With the Cyrus service and bm-elasticsearch sur des serveurs dédiéson 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 data for storage devices (wikipedia)

Source: http://en.wikipedia.org/wiki/IOPS

Examples

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/PDA places heavy demands on) must be kept separate from the rest.

Bandwidth

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 PDAs 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):

• every 30 seconds: one doSync 1067 / 293 (sends local modifications and retrieves changes)
• every 5 seconds: one ping: 898 / 233, i.e. 5388 / 1398 in 30s (one keepalive)

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:

• Client to server: 500KB/s
• Server to client: 150KB/s

Contacts bandwidth

For a user with the Contacts application running in their browser, in http and in bytes:

144 bytes/second

Specifically:

• a ping every 5 seconds
• a "bmc" every 30 seconds

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.

PDA bandwidth

Microsoft provides the following ActiveSync ratios: 1.04KB/s/user

i.e. for 100 PDAs: 104Kbit, or 13KB/s

By taking a sensible safety margin of x2, we calculate:

• 100 PDAs == 26KB/s
• 1,000 PDAs == 260KB/s