About units

Several BlueMind components use up resources. A standard "per user" calculation cannot be applied because a user who only uses email will not generate the same system load as a user using email and collaborative services (Calendar, etc.) and a smartphone.

As a result, sizing is calculated on a "per unit" basis:

Also, for a same amount of units, a use of email only will not consume the same amount of resources as an email+collaborative use: unlike collaborative tools, email, 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

*With the Cyrus service and bm-elasticsearch on dedicated servers 

Storage / IO Performance

The email 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.)

Minimum disk performance 

The email service being IO hungry, storage is sized in IOPS. The storage space itself directly depends on client requirements (quotas etc.).

Depending on the final usage, all the disks do not require the same performance levels. Below are the minimum IOPS for any installation:

Mount Point	Description	Type		Minimum IOPS
		NFS	block device
/var/lib/postgresql	PostgreSQL database			10,000 iops
/var/spool/cyrus/meta	email metadata			10,000 iops
/var/spool/cyrus/data	emails			6,000 iops
/var/spool/bm-hsm	archived emails			6,000 iops
/var/spool/bm-elasticsearch	search index			10,000 iops
/var/spool/bm-mail	EAS/mapi Email Service ~2Go			6,000 iops
/var/log	logs			6,000 iops
/var/backups/bluemind	sauvegardes			6,000 iops

For installations with more than 2,000 users, expected iops can be calculated based on the number of users and usage:

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 email part as well as the database (which collaborative use/smartphone 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 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):

• 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 maneuvre, 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.

Smartphone bandwidth

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:

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