grommunio améliore la performance des boîtes aux lettres

Elle est déjà incluse dans la version communautaire et sera bientôt packagée et disponible pour tous les clients de grommunio : Grâce à un changement dans la manière dont grommunio gère les bases de données de boîtes aux lettres électroniques, les équipes bénéficieront d’une amélioration significative de la performance des boîtes aux lettres.

Le problème est complexe, mais très répandu : Dans le passé, il pouvait arriver que les utilisateurs subissent des temps d’attente plus longs lorsque de nombreux clients accédaient à des boîtes aux lettres individuelles en même temps, par exemple lorsque plusieurs utilisateurs effectuaient des recherches plus longues sur une boîte aux lettres en même temps, comme lorsqu’ils se préparaient à une réunion. La raison en est le souci de cohérence des données : un seul client à la fois peut accéder aux données d’une boîte aux lettres et y apporter des modifications, après quoi c’est au tour du client suivant - sinon, il y a risque d’incohérences. Cet accès “en série” (c’est-à-dire l’un après l’autre) peut prendre beaucoup de temps, en particulier avec des ensembles de données plus importants (et de nombreux clients souhaitant y accéder en même temps). Le problème n’est pas limité à grommunio, mais s’applique en principe à tous les services web et de messagerie : Si vous voulez des données cohérentes, vous devez traiter les accès les uns après les autres ; si vous voulez des performances élevées, vous devez paralléliser les accès. Mais il existe des solutions intelligentes qui peuvent aider à résoudre ce dilemme. grommunio a mis en œuvre l’une d’entre elles et a ainsi obtenu une augmentation importante des performances.

Écriture et lecture seule : série ou parallèle ?

La solution au problème : on fait la distinction entre l’accès en écriture et l’accès en lecture seule. L’accès en lecture seule (par exemple, la mise à jour d’un dossier partagé par un client de messagerie) peut être autorisé par le serveur en parallèle par plusieurs clients en même temps, et la mise en cache est également possible. Une “source unique de vérité” n’est requise que pour l’écriture, c’est-à-dire l’accès exclusif par un seul client - sinon des données incohérentes peuvent apparaître ou un client peut écraser les modifications apportées par un autre.

La mise en œuvre de cette technique nécessite une certaine compréhension du fonctionnement de grommunio (ou de tout autre serveur de courrier et de base de données). Dans grommunio, il existe une base de données MySQL centrale pour les métadonnées et les caches pour les métadonnées de l’utilisateur, c’est-à-dire une grande table avec toutes les données, y compris, par exemple, la table des matières pour les informations sur les utilisateurs et l’affectation de l’emplacement exact de la boîte aux lettres d’un utilisateur.

Il existe également une base de données SQLite pour chaque utilisateur, qui contient les données spécifiques de l’utilisateur, y compris tous les courriels. Pour l’utilisateur individuel, il s’agit également de l’élément central de la boîte aux lettres, mais elle peut également constituer un goulot d’étranglement si de nombreuses demandes arrivent en même temps. Néanmoins, le système est flexible et a fait ses preuves, il peut être dimensionné en fonction des besoins et constitue un élément important de la performance élevée de la boîte aux lettres de grommunio.

Cependant, si un client effectue une recherche dans une boîte aux lettres plus grande, par exemple, celle-ci est bloquée pour d’autres demandes jusqu’à ce que la demande de recherche ait été entièrement traitée. Du côté du serveur, ceci est mis en œuvre via un [Mutex] (https://stackoverflow.com/questions/34524/what-is-a-mutex), les autres clients doivent attendre et, dans le pire des cas, se heurtent à un dépassement de délai - ce qui signifie un message d’erreur pour l’utilisateur.

Problème avec le mutex du serveur exmdb typique : Le thread 1 verrouille le mutex et travaille avec la ressource partagée, tandis que le thread 2 est bloqué par le mutex et doit attendre.

Augmentation des performances de la boîte aux lettres grâce à un serveur de gestion qui prend des décisions en fonction de la situation

Étant donné que le Mutex n’a pas vraiment de sens pour les requêtes de recherche ou les accès en lecture seule similaires, car la base de données n’est pas modifiée, les développeurs de grommunio ont mis en œuvre une solution qui élimine ce goulot d’étranglement. Les développeurs ont adapté le [serveur de gestion (exmdb)] (https://docs.grommunio.com/man/exmdb_provider.4gx.html) à cet effet. Il est complexe et a déjà coordonné l’accès avec ses plus de 120 fonctions. Pour intégrer la parallélisation de l’accès en lecture seule, les développeurs ont dû adapter plus de 18 000 lignes de code. Alors qu’auparavant, un Mutex par boîte aux lettres permettait d’éviter les conflits, mais provoquait aussi parfois des encombrements, le nouveau système se passe d’un “grand” Mutex, inspectant chaque demande et décidant au cas par cas si elle peut être parallélisée en toute sécurité.

Amélioration avec le serveur exmdb adapté : Thread 1 et Thread 2 reçoivent une réponse plus rapide de la ressource partagée.

“Cette approche s’est avérée nettement plus rapide et plus souple, et elle est perceptible pour toutes les équipes qui utilisent des boîtes aux lettres partagées, en particulier dans le cadre de leur travail quotidien. Un exemple typique est la préparation conjointe d’une réunion d’équipe, où tous les participants veulent se mettre à jour rapidement les uns les autres dans les heures qui précèdent la réunion. Mais ce n’est qu’un exemple, les utilisateurs nous parlent avec enthousiasme d’autres situations qui ont été considérablement accélérées par le changement. “Michael Kromer, directeur technique de grommunio.

Découvrez d’autres fonctionnalités de grommunio.