Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space DA and version BM-4
Sv translation
languagefr

Présentation

Les données indiquées ici le sont à titre indicatif. En effet, pour un même nombre d’utilisateurs, l’utilisation peut-être très différente selon les structures et habitudes. Le nombre de mails, leur taille, le nombre de destinataires dans les mails, le nombre de rdv, de planification... tout ceci par jour est très variable.

Panel
borderWidth3

Sur cette page :

Table of Contents
maxLevel2

En rapport :

Le principe des unités

Dans un système comme BlueMind, il y a différents composants consommateurs de ressources.

Le calcul basique “par utilisateur” n’est plus valide car un utilisateur qui n’utilise que la partie messagerie ne sollicitera pas le système de la même façon qu’un utilisateur utilisant le mail et les outils collaboratifs (agenda,..), notamment avec un smartphone.

Le calcul du dimensionnement s’effectue donc par unité sachant que :

Profil d’utilisateur

Coût en unité

Messagerie seule

1

Messagerie + collaboratif intensif

2

Messagerie + collaboratif + smartphone

5

De même pour un même nombre d’unité, une utilisation uniquement messagerie n’aura pas la même consommation de ressources qu’une utilisation messagerie + collaboratif (pour la moitié d’utilisateurs). Le mail étant par exemple plus dépendant des IO que du CPU, ce qui est inverse en général des outils collaboratifs.

CPU

Nous parlons en nombre de cœurs. La référence est un CPU serveur récent, de type Xeon.

BlueMind comprend de nombreux services, nous préconisons donc 2 cœurs minimum.

A noter qu'allouer trop de CPU peut mener à d'autres problèmes sur des environnements virtualisés (https://techan.fr/problemes-de-performance-sur-vmware-du-a-du-cpu-ready.html)

Unitésnombre de cœurs
1-2002
200-10004
1000-20006
2000-30008
3000-600012
6000+2 cœurs / 1000 unités

RAM

UnitésRam
1-25016 Go
250-100024 Go
1000-250032 Go
2500 - 500048 Go
5000-1000064 Go*
10000+96 Go*

*avec déport du service Cyrus et bm-elasticsearch sur des serveurs dédiés

Stockage / IO


Info
titleDisques et performance

Un messagerie sollicite beaucoup les disques, pour la lecture et l'écriture de petits fichiers, mais aussi pour tous les traitements sur les messages (indexation, état de lecture, etc...). La qualité des disques et leur rapidité est une donnée clé d'une messagerie performante.

Info

IOPS = «In/Out per second», soit «Entrée/Sorties par seconde»

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 :

point de montagedescriptiontype

IOPS

minimum

NFSblock device
/var/lib/postgresqlBase de données PostgreSQL(error)(tick)10 000 iops
/var/spool/cyrus/metameta données des e-mail(error)(tick)10 000 iops
/var/spool/cyrus/dataemails(error)(tick)6 000 iops
/var/spool/bm-hsmemails archivés(tick)(tick)6 000 iops
/var/spool/bm-elasticsearchindex de recherche(error)(tick)10 000 iops
/var/spool/bm-mailenvoi des emails via EAS/mapi
~2Go
(tick)(tick)6 000 iops
/var/loglogs (fichiers journaux)(tick)(tick)6 000 iops
/var/backups/bluemindsauvegardes(tick)(tick)6 000 iops

Pour les installations supérieures à 2000 utilisateurs, les iops attendus peuvent être calculés selon le nombre d'utilisateurs et l'usage :


Unités

IOPS par unité

1

1

Données sur les IOPS des moyens de stockage (wikipedia)

Device  

Type  

IOPS  

Interface  

Notes  

7,200 rpm   SATA drives

HDD  

~75-100 IOPS [2]  

SATA 3 Gb/s  


 

10,000 rpm SATA drives

HDD

~125-150 IOPS [2]  

SATA 3 Gbit/s


 

10,000 rpm SAS drives

HDD

~140 IOPS [2]  

SAS


 

15,000 rpm SAS drives

HDD

~175-210 IOPS [2]  

SAS


Vérification de la performance de vos disques

Info
titleAttention

Effectuez ces tests en respectant bien les consignes. Il est possible de détruire des données ou impacter les performances du serveur si les opérations ne sont pas réalisées avec précaution.

Vous pouvez vérifier la performance de vos disques en utilisant la procédure de test suivante :

[Système] Commandes (à déplacer dans Troubleshooting de la v4 ?)

Exemples

La répartition des cœurs / ram sur plusieurs serveurs (virtuels ou non) n’est pas décrite ici.

Cependant jusqu’à 16/24 cœurs, nous considérons pertinent d’installer l’ensemble sur une même plateforme.

Au dela de ceci, et pour gérer les populations en dizaine ou plus de milliers d’utilisateurs, l’architecture doit être distribuée.

Ensuite, la partie messagerie doit être séparée, ainsi que la base de données (très sollicitée par le collaboratif / smartphones).

Users / unités

Noeud

CPU

#cœurs

RAM

en Go

IOPS / Disque

25 utilisateurs / 5 avec smartphones

45 unités (20 + 25)


2

16

13,5 / tout disque

150 utilisateurs / 50 collaboratifs dont 25 avec smartphones

225 unités (100+25*2+25*5)


4

16

67,5

SATA 7200 minimum

300 utilisateurs / 100 collaboratifs / 30 smartphones

490 unités (200 + 70*2 + 30*5)


4

24

147

2 * 10K rpm SAS

1 * 15K rpm SAS

600 utilisateurs / 200 collaboratifs / 50 smartphones

950 unités (400 + 150*2 * 50*5) → 4 CPU, 24 Go de RAM

Core

2

20

285

SSD, Baie ou autre système

Edge24

1000 util. / 250 collaboratifs / 100 smartphones

1300 unités (750 + 150 * 2 + 100 * 5) → 6 CPU, 32 Go de RAM

Core

2

20

390

SSD, Baie ou autre système

BM-ES28ES dédié à partir d'1To de mails et archives
Edge24

2000 util. / 500 collaboratifs / 200 smartphones

3100 unités (1500 + 300*2 + 200 * 5) → 12 CPU, 48Go de RAM

Core

6

20

930

Baie (2000 IOPS)

BM-ES212ES dédié à partir d'1To de mails et archives

Cyrus

212Cyrus dédié à partir de 2 To de mails et archives
Edge24

4000 util. / 1000 collaboratifs / 300 smartphones

5900 unités (3000 + 700*2 + 300*5) → 12 CPU, 64Go de RAM

Core

6

36

1770

Baie (2-3000 IOPS)

BM-ES212ES dédié à partir d'1To de mails et archives

Cyrus

212Cyrus dédié à partir de 2 To de mails et archives
Edge24

4000 util. / 1000 collaboratifs / 1000 smartphones

8000 unités (3000 + 1000*5) → 16 CPU, 64Go de RAM

Core

6

36

2400

BAIE 3000 IOPS

SAN / autre techno

BM-ES412ES dédié à partir d'1To de mails et archives

Cyrus

412Cyrus dédié à partir de 2 To de mails et archives
Edge24

4000 util. / 4000 collaboratifs / 1000 smartphones

11000 unités (3000*2 + 1000*5) → 22 CPU, 96Go de RAM

Core

10

44

3300

SAN / autre techno

BM-ES424ES dédié à partir d'1To de mails et archives

Cyrus

624

Cyrus dédié à partir de 2 To de mails et archives

2e noeud Cyrus à envisager

Edge24

5000 utilisateurs et + (10 000, 100 000,..)

Le système doit être distribué et l’architecture étudiée en fonction du contexte particulier.





Bande passante

La bande passante nécessaire n’est pas prévisible car elle dépend en très grande partie du trafic mail.

A titre d’informations ci-dessous les informations sur la consommation bande passante de l’agenda BlueMind et des smartphones, qui montre bien la prédominance du trafic mail.

Bande passante Agenda BlueMind

Pour un utilisateur avec l'application d'agenda ouverte dans son navigateur, en http et en octets (mesuré sur le réseau avec wireshark) :

  • toutes les 30 sec: un "doSync" 1067 / 293 (envoie des modifs locales et récupération des changements)
  • toutes les 5 sec: un "ping": 898 / 233, soit 5388 / 1398 en 30 s(un "keep alive")

Client vers serveur: 215 octets/sec (1067+5388)/30

Server vers client: 56 octets/sec (293+1398)/30

# utilisateurs actifs

client vers serveur

serveur vers client

1

215 octets/s

56 octets/s

100

21 ko/s

6 ko/s

1 000

210 ko/s

60 ko/s

10 000

2,1 Mo/s

600 ko/s

Avec de la marge, pour 1000 agendas ouverts dans les navigateurs :

  • Client vers serveur: 500ko/sec.
  • Serveur vers client: 150ko/sec.

Bande passante de la gestion des contacts

Pour un utilisateur avec l'application de gestion des contacts ouverte dans son navigateur, en http et en octets :

144 octets / seconde

Avec en particulier :

  • toutes les 5 secondes un "ping"
  • toutes les 30 secondes un "bmc"

En prenant une marge de sécurité en doublant la valeur mesurée, nous obtenons une bande passant de 288 octets par seconde pour un utilisateur ayant lancé l'application de gestion de contacts.

Bande passante smartphones

Les ratios ActiveSync sont  fournis par microsoft : 1.04kb /sec/user

soit pour 100 smartphones : 104Kb, donc 13Ko/sec

Pour lequel nous prendrons une marge raisonnable de x2, ce qui donne :

100 smartphones == 26 Ko/sec

1 000 smartphones == 260 Ko/sec

Sv translation
languageen

Introduction

The data in this page is provided for information purposes only. Usage may vary for a same number of users, depending on hardware structure and use habits. Many factors can affect usage: email volume, email size, number of recipients, number of events, event scheduling, etc.

Panel
borderWidth3

On this page:

Table of Contents
maxLevel2

Related:

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

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

User profile

Units

Messaging only

1

Messaging + intense collaborative use

2

Messaging + collaborative services + smartphone

5

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)

Units

Number of core(s)

1-200

2

200-1000

4

1000-20006
2000-30008
3000-600012

6000+

2 / 1000 units

RAM

Units

RAM

1-25016 GB
250-100024 GB
1000-250032GB
2500-500048GB
5000-10,00064GB*
10,000+96GB*

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

Storage / IO Performance

Info
titleDisques et performance

Un messagerie sollicite beaucoup les disques, pour la lecture et l'écriture de petits fichiers, mais aussi pour tous les traitements sur les messages (indexation, état de lecture, etc...). La qualité des disques et leur rapidité est une donnée clé d'une messagerie performante.

Info

IOPS = "Input/Output Operations Per Second"

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

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 :

point de montagedescriptiontype

IOPS

minimum

NFSblock device
/var/lib/postgresqlBase de données PostgreSQL(error)(tick)10 000 iops
/var/spool/cyrus/metameta données des e-mail(error)(tick)10 000 iops
/var/spool/cyrus/dataemails(error)(tick)6 000 iops
/var/spool/bm-hsmemails archivés(tick)(tick)6 000 iops
/var/spool/bm-elasticsearchindex de recherche(error)(tick)10 000 iops
/var/spool/bm-mailenvoi des emails via EAS/mapi
~2Go
(tick)(tick)6 000 iops
/var/loglogs (fichiers journaux)(tick)(tick)6 000 iops
/var/backups/bluemindsauvegardes(tick)(tick)6 000 iops

Pour les installations supérieures à 2000 utilisateurs, les iops attendus peuvent être calculés selon le nombre d'utilisateurs et l'usage :


Unités

IOPS par unité

1

1


IOPS data for storage devices (wikipedia)


Device  

Type  

IOPS  

Interface  

Notes  

7,200 rpm   SATA drives

HDD

~75-100 IOPS [2]

SATA 3 Gb/s


 

10,000 rpm SATA drives

HDD

~125-150 IOPS [2]  

SATA 3 Gbit/s


 

10,000 rpm SAS drives

HDD

~140 IOPS [2]

SAS


 

15,000 rpm SAS drives

HDD

~175-210 IOPS [2]

SAS



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

Users / Units

Node

CPU

#cores

RAM

IOPS / Disk

25 users / 5 with smartphones

45 units (20 + 25)


2

16

13.5 / all disks

150 users / 50 collaborative users of which 25 with smartphones

225 units (100+25*2+25*5)


4

16

67.5

SATA 7,200 minimum

300 users / 100 collaborative users / 30 smartphones

490 units (200 + 70*2 + 30*5)


4

24

147

2 * 10K rpm SAS

1 * 15K rpm SAS

600 users / 200 collaborative users / 50 smartphones

950 units (400 + 150*2 * 50*5) → 4 CPU, 24 GB of RAM

Core

2

20

285

SSD, Bay or other system

Edge24

1,000 users / 250 collaborative users / 100 Psmartphones

1,300 units (750 + 150 * 2 + 100 * 5) → 6 CPU, 32 GB of RAM

Core

2

20

390

SSD, Bay or other system

BM-ES28dedicated ES for more than 1TB of emails and archives
Edge24

2,000 users / 500 collaborative users / 200 smartphones

3,100 units (1500 + 300*2 + 200 * 5) → 12 CPU, 48GB of RAM

Core

6

20

930

Bay (2,000 IOPS)

BM-ES212dedicated ES from 1TB of emails and archives
Cyrus212dedicated Cyrus from 2TB of emails and archives
Edge24

4,000 users / 1000 collaborative users / 300 smartphones

5,900 units (3000 + 700*2 + 300*5) → 12 CPU, 64GB of RAM

Core

6

36

1,770

Bay (2-3,000 IOPS)

BM-ES212dedicated ES from 1TB of emails and archives
Cyrus212dedicated Cyrus from 2TB of emails and archives
Edge24

4,000 users / 1000 collaborative users / 1000 smartphones

8,000 units (3000 + 1000*5) → 16 CPU, 64GB of RAM

Core

6

36

2,400

Bay 3,000 IOPS

SAN / other technology

BM-ES412dedicated ES from 1TB of emails and archives
Cyrus412dedicated Cyrus from 2TB of emails and archives
Edge24

4,000 users / 4,000 collaborative users / 1000 smartphones

1,1000 units (3,000*2 + 1,000*5) → 22 CPU, 96GB of RAM

Core

10

44

3,300

SAN / other technology

BM-ES424dedicated ES from 1TB of emails and archives
Cyrus424

dedicated Cyrus from 2TB of emails and archives

consider 2 cyrus nodes

Edge24

5,000+ users (10,000; 100,000; etc.)

The system must be distributed and the architecture designed on an ad-hoc basis.





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

Number of active users

Client to Server

Server to Client

1

215 B/s

56 B/s

100

21 KB/s

6 KB/s

1,000

210 KB/s

60 KB/s

10,000

2.1 MB/s

600 KB/s

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.

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
Sv translation
languageit

Sv translation
languagede

Präsentation

Die hier angegebenen Daten sind unverbindlich. In der Tat kann die Nutzung bei gleicher Anzahl von Benutzern je nach Struktur und Gewohnheiten sehr unterschiedlich sein. Die Anzahl der E-Mails, ihre Größe, die Anzahl der Empfänger in den E-Mails, die Anzahl der Termine, die Planung usw. fallen täglich sehr unterschiedlich aus.

Panel
borderWidth3

Auf dieser Seite:

Table of Contents
maxLevel2

Verwandt:

Das Prinzip der Einheiten

In einem System wie BlueMind gibt es verschiedene ressourcenverbrauchende Komponenten.

Die „pro Benutzer“-Basisberechnung ist nicht gültig, da ein Benutzer, der nur die Mailbox verwendet, das System nicht in der gleichen Weise beansprucht wie einer, der E-Mail und kollaborative Tools (Kalender usw.) nutzt, insbesondere mit einem Smartphone.

Die Berechnung der Dimensionierung erfolgt daher pro Rechner, wobei:

Benutzerprofil

Preis pro Einheit

Nur Mailbox

1

Mailbox + intensiv kollaborativ

2

Mailbox + kollaborativ + Smartphone

5

Ebenso wird bei gleicher Anzahl von Einheiten eine reine Mailbox-Nutzung nicht den gleichen Ressourcenverbrauch aufweisen wie eine Mailbox + Kollaborationsnutzung (für die Hälfte der Benutzer). Zum Beispiel ist die E-Mail mehr von IO als von CPU abhängig, was im Allgemeinen das Gegenteil von kollaborativen Tools ist.

CPU

Anzahl der Kerne (Cores). Die Referenz ist eine aktuelle Server-CPU, Typ Xeon.

BlueMind enthält viele Dienste, daher empfehlen wir mindestens 2 Kerne.

Beachten Sie, dass die Zuweisung von zu vielen CPUs zu anderen Problemen in virtualisierten Umgebungen führen kann (https://techan.fr/problemes-de-performance-sur-vmware-du-a-du-cpu-ready.html)

EinheitenAnzahl der Kerne
1-2002
200-10004
1000-20006
2000-30008
3000-600012
6000+2 Kerne / 1000 Einheiten

RAM

EinheitenRam
1-25016 GB
250-100024 GB
1000-250032 GB
2500 - 500048 GB
5000-1000064 GB*
10000+96 GB*

*mit Verschiebung des Dienstes Cyrus und bm-elasticsearch auf dedizierte Server

Speicherung / IO

Info

IOPS = „In/Out per second“, d.h. „Ein-/Ausgabe pro Sekunde“

Der Speicher wird in IOPS bemessen, da ein Mailbox-Dienst viele IOs verbraucht. Der Speicherplatz ist direkt abhängig vom Bedarf des Kunden (Kontingente usw.)

Einheiten

IOPS pro Einheit

1

.3

IOPS-Daten der Speichermedien (Wikipedia)

Gerät  

Typ  

IOPS  

Schnittstelle  

Hinweise  

7.200 U/min.   SATA Laufwerke

HDD  

~75-100 IOPS [2]  

SATA 3 Gbit/s  


 

10.000 U/min SATA-Laufwerke

HDD

~125-150 IOPS [2]  

SATA 3 Gbit/s


 

10.000 U/min SAS Laufwerke

HDD

~140 IOPS [2]  

SAS


 

15.000 U/min SAS Laufwerke

HDD

~175-210 IOPS [2]  

SAS


Beispiele

Die Verteilung von Kernen / Ram auf mehrere Server (virtuell oder nicht) wird hier nicht beschrieben.

Bis zu 16/24 Kernen halten wir es jedoch für sinnvoll, das Ganze auf der gleichen Plattform zu installieren.

Darüber hinaus und zur Verwaltung von zehn oder tausenden von Benutzern muss die Architektur verteilt sein.

Dann muss der Mailbox-Teil getrennt werden, ebenso wie die Datenbank (sehr beansprucht bei den kollaborativen Teilen / Smartphones).

Benutzer / Einheiten

Knoten

CPU

#Kerne

RAM

in GB

IOPS / Festplatte

25 Benutzer / 5 mit Smartphones

45 Einheiten (20 + 25)


2

16

13,5 / beliebige Festplatte

150 Benutzer / 50 Mitarbeiter, davon 25 mit Smartphones

225 Einheiten (100+25*2+25*5)


4

16

67,5

SATA 7200 mindestens

300 Benutzer / 100 Mitarbeiter / 30 Smartphones

490 Einheiten (200 + 70*2 + 30*5)


4

24

147

2 * 10K U/min SAS

1 * 15K U/min SAS

600 Benutzer / 200 Mitarbeiter / 50 Smartphones

950 Einheiten (400 + 150*2 * 50*5) → 4 CPU, 24 GB RAM

Kern

2

20

285

SSD, Rack oder anderes System

Edge24

1000 Ben. / 250 Mitarbeiter / 100 Smartphones

1300 Einheiten (750 + 150 * 2 + 100 * 5) → 6 CPU, 32 GB RAM

Kern

2

20

390

SSD, Rack oder anderes System

BM-Speicherplatz28Dedizierter Speicherplatz ab 1TB E-Mails und Archive
Edge24

2000 Ben. / 500 Mitarbeiter / 200 Smartphones

3100 Einheiten (1500 + 300*2 + 200 * 5) → 12 CPU, 48 GB RAM

Kern

6

20

930

Rack (2000 IOPS)

BM-Speicherplatz212Dedizierter Speicherplatz ab 1TB E-Mails und Archive

Cyrus

212Dedizierter Cyrus ab 2 TB E-Mails und Archive
Edge24

4000 Ben. / 1000 Mitarbeiter / 300 Smartphones

5900 Einheiten (3000 + 700*2 + 300*5) → 12 CPU, 64 GB RAM

Kern

6

36

1770

Rack (2-3000 IOPS)

BM-Speicherplatz212Dedizierter Speicherplatz ab 1TB E-Mails und Archive

Cyrus

212Dedizierter Cyrus ab 2 TB E-Mails und Archive
Edge24

4000 Ben. / 1000 Mitarbeiter / 1000 Smartphones

8000 Einheiten (3000 + 1000*5) → 16 CPU, 64 GB RAM

Kern

6

36

2400

RACK 3000 IOPS

SAN / andere Techno

BM-Speicherplatz412Dedizierter Speicherplatz ab 1TB E-Mails und Archive

Cyrus

412Dedizierter Cyrus ab 2 TB E-Mails und Archive
Edge24

4000 Ben. / 4000 Mitarbeiter / 1000 Smartphones

11000 Einheiten (3000*2 + 1000*5) → 22 CPU, 96 GB RAM

Kern

10

44

3300

SAN / andere Techno

BM-Speicherplatz424Dedizierter Speicherplatz ab 1TB E-Mails und Archive

Cyrus

624

Dedizierter Cyrus ab 2 TB E-Mails und Archive

2. Cyrus-Knoten zu berücksichtigen

Edge24

mehr als 5000 Benutzer (10.000, 100.000 usw.)

Das System muss verteilt sein und die Architektur entsprechend dem jeweiligen Kontext untersucht werden.





Bandbreite

Die benötigte Bandbreite ist nicht vorhersehbar, da sie sehr stark vom E-Mail-Verkehr abhängt.

Als Information nachstehend der Bandbreitenverbrauch des BlueMind-Kalenders und der Smartphones, der die Dominanz des E-Mail-Verkehrs aufzeigt.

Bandbreite BlueMind Kalender

Für einen Benutzer, der die Kalenderanwendung in seinem Browser geöffnet hat, in http und Bytes (gemessen über das Netzwerk mit Wireshark:

  • alle 30 Sekunden: ein „doSync“ 1067 / 293 (sendet lokale Änderungen und ruft Änderungen ab)
  • alle 5 Sekunden: ein „Ping“: 898 / 233, d.h. 5388 / 1398 in 30 s (ein „keep alive“)

Client an Server: 215 Bytes/Sek. (1067+5388)/30

Server an Client: 56 Bytes/Sek. (293+1398)/30

# aktive Benutzer

Client an Server

Server an Client

1

215 Bytes/Sek.

56 Bytes/Sek.

100

21 KB/Sek.

6 KB/Sek.

1000

210 KB/Sek.

60 KB/Sek.

10000

2,1 MB/Sek.

600 KB/Sek.

Mit Marge, für 1000 geöffnete Kalender in den Browsern:

  • Client an Server: 500 KB/Sek.
  • Server an Client: 150 KB/Sek.

Bandbreite der Kontaktverwaltung

Für einen Benutzer, der die Kontaktverwaltungsanwendung in seinem Browser geöffnet hat, in http und Bytes:

144 Bytes / Sekunde

Und mit:

  • alle 5 Sekunden ein „Ping“
  • alle 30 Sekunden ein „bmc“

Unter Berücksichtigung einer Sicherheitsmarge durch Verdoppelung des gemessenen Wertes erhalten wir eine Bandbreite von 288 Byte pro Sekunde für einen Benutzer, der die Kontaktverwaltungsanwendung gestartet hat.

Smartphone-Bandbreite

Die ActiveSync-Kennzahlen werden von Microsoft bereitgestellt: 1.04KB /Sek./Benutzer

oder für 100 Smartphones: 104KB, also 13KB/Sek

Dafür nehmen wir einen angemessenen Spielraum von x2 an, dies ergibt:

100 Smartphones == 26 KB/Sek.

1.000 Smartphones == 260 KB/Sek.