Correction des problèmes de latence et de lenteur de l'accès aux salles lors de la fédération Matrix Synapse

Commencez par localiser le retard.

Lorsqu'une salle Matrix met longtemps à s'ouvrir ou à être rejointe, commencez par déterminer si le délai affecte un seul serveur distant, une seule salle ou l'ensemble de votre instance Synapse. Cette distinction est importante : la fédération est un échange bidirectionnel entre les serveurs, et l'accès à une salle peut impliquer plusieurs serveurs. Les lenteurs d'accès peuvent être dues à votre processus Synapse, au serveur distant, au routage DNS ou TLS, à la base de données, ou encore à la taille et à l'état de la salle. Il n'existe pas d'option unique pour réduire le délai de fédération et résoudre tous ces problèmes.

Vérifié : Synapse enregistre les informations de nouvelle tentative de connexion à la destination distante, expose les métriques Prometheus et inclut des limites de débit pour les connexions aux salles. Dépend de la situation : lequel de ces éléments est responsable d’une connexion lente ? Impossible de le savoir d’après le seul symptôme : le serveur principal ou un réseau intermédiaire est-il lent ? Commencez par un utilisateur concerné, une salle et l’heure approximative de la tentative lente ; comparez ces détails avec une salle témoin qui se connecte normalement.

Vérifier si la fédération est accessible

Utilisez l'outil officiel de test de fédération Matrix avec le nom de serveur Matrix de votre serveur domestique. Il peut révéler les problèmes courants de DNS, de délégation, de certificat et d'accessibilité. Le nom du serveur dans les identifiants utilisateur peut différer de la machine ou du proxy qui héberge Synapse ; vérifiez donc le point de terminaison de fédération et la délégation configurés plutôt que de supposer que le domaine de l'identifiant utilisateur héberge nécessairement Synapse directement.

La documentation de Synapse sur la fédération indique que le port de fédération par défaut est le port TCP 8448, tandis que les déploiements délégués ou utilisant un proxy inverse peuvent utiliser le port HTTPS 443. Le port concerné doit être accessible depuis les autres serveurs d'accueil, et les pare-feu sortants peuvent également devoir autoriser le trafic de fédération. Vérifiez les règles de pare-feu entrantes et sortantes correspondantes, puis effectuez un nouveau test à l'aide de l'outil de test de fédération. N'ouvrez pas les deux ports simultanément si votre déploiement est configuré pour n'en utiliser qu'un seul.

Un résultat affichant une erreur de certificat, de DNS ou de routage indique un problème de configuration ou d'accessibilité réseau, et non un problème de capacité du serveur. Vérifiez les enregistrements DNS et la délégation du nom du serveur Matrix, la chaîne de certificats TLS du proxy inverse et assurez-vous que le proxy transmet bien les chemins de fédération à Synapse. Synapse indique qu'une redirection permanente 308 n'est pas toujours suivie par les serveurs fédérés dans certaines configurations ; il est donc important d'examiner également les redirections inattendues. Corrigez le problème spécifique et effectuez un nouveau test avant de modifier le nombre de nœuds de calcul ou les limites de débit.

Référence : Configuration et dépannage de la fédération Synapse et guide du pare-feu Synapse .

Vérifiez si un serveur distant est en période de temporisation de nouvelle tentative.

Synapse marque temporairement une destination distante comme hors ligne après l'échec de requêtes de fédération. Les délais de nouvelle tentative utilisent un mécanisme de temporisation, ce qui peut entraîner des retards apparents dans les messages ou les connexions impliquant cette destination en cas d'échecs répétés. Cela ne signifie pas que votre serveur principal est lent : il peut s'agir d'un seul serveur distant inaccessible ou renvoyant des échecs de requêtes.

Les administrateurs peuvent consulter l'API d'administration de fédération de Synapse, qui est documentée GET /_synapse/admin/v1/federation/destinations. Utilisez un jeton d'accès d'administrateur serveur et conservez-le confidentiel. Examinez les enregistrements de destination et les champs de nouvelle tentative du serveur principal concerné par la salle affectée. Ces enregistrements permettent d'identifier les tentatives de reconnexion, mais ne prouvent pas à eux seuls la cause de l'échec. Corrélez-les avec les journaux Synapse, les journaux de proxy, les tests DNS/TLS et les heures auxquelles les utilisateurs ont signalé des problèmes.

L'API d'administration de la fédération est documentée comme expérimentale et susceptible d'évoluer. Évitez de l'utiliser comme s'il s'agissait d'une API client publique stable. Synapse documente également une opération de réinitialisation du délai d'expiration de la connexion qui peut déclencher une nouvelle tentative en arrière-plan pour une destination déjà en attente. N'utilisez cette opération qu'à des fins de diagnostic ou de récupération, après avoir corrigé ou compris la cause du problème ; la réinitialisation répétée des délais d'expiration ne permettra pas à un serveur distant défaillant de répondre. Une réponse HTTP positive du point de terminaison de réinitialisation ne signifie pas que la tentative de fédération en arrière-plan est terminée.

Référence : API d’administration de Synapse Federation . Le statut expérimental et les champs disponibles de l’API peuvent varier selon les versions de Synapse ; veuillez donc consulter la documentation de la version que vous utilisez avant toute opération.

Mesurez Synapse et sa base de données avant la mise à l'échelle.

N'activez le point de terminaison des métriques Prometheus de Synapse que sur un réseau interne de confiance ou protégé par des contrôles d'accès. Le guide de surveillance officiel /_synapse/metricsexplique comment l'exposer via un écouteur de métriques ou un écouteur HTTP existant. Les métriques peuvent inclure des informations opérationnelles ; ne publiez pas ce point de terminaison publiquement. Si vous collectez déjà des métriques, comparez le temps d'une jointure lente avec l'utilisation du processeur, de la mémoire, la latence des requêtes, la durée des transactions de base de données et l'activité de fédération entrante et sortante.

Utilisez les graphiques pour distinguer une surcharge générale des ralentissements spécifiques à la fédération. Si les requêtes client et les transactions de base de données ralentissent simultanément aux jointures, examinez la charge du processeur et de la mémoire de l'hôte, l'état de PostgreSQL, les limites de connexion, la latence du disque et les requêtes longues. Si l'activité locale reste réactive, mais qu'une destination distante présente des défaillances ou des délais de nouvelle tentative, priorisez l'accessibilité de la fédération et ce serveur distant. Si une seule grande salle est affectée, son état et le nombre de serveurs participants peuvent être en cause ; comparez-la avec une salle plus petite avant de tirer des conclusions.

Le guide Grafana de Synapse recommande de vérifier le temps d'envoi des messages, l'utilisation du processeur et de la mémoire, le nombre et la durée des transactions de la base de données, ainsi que les graphiques de fédération. Un nombre élevé de transactions n'indique pas systématiquement un goulot d'étranglement ; la durée et la charge système sont également importantes. Consultez les noms des métriques de votre version de Synapse et la documentation du tableau de bord, car les métriques ont été renommées au fil du temps.

Références : Surveillance et compréhension de Synapse Prometheus via les graphiques Grafana .

Vérifiez la limitation et les rafales lors de l'ajout à une salle.

Synapse applique rc_joinsdes limites distinctes aux connexions locales et distantes. Une connexion distante peut nécessiter plus d'efforts que de rejoindre une salle à laquelle le serveur participe déjà. Synapse dispose également rc_joins_per_roomd'une limitation du nombre de connexions récentes à une salle afin d'atténuer les pics de connexion. Si les journaux ou les réponses du client indiquent une limitation du débit, vérifiez ces paramètres et le volume de connexions récentes avant de les modifier.

N’augmentez pas les limites de requêtes pour améliorer la vitesse de manière générale. Des limites plus élevées peuvent accroître la charge sur votre serveur et les autres serveurs de votre réseau, et réduire la protection contre les pics de requêtes. Si une migration ou une intégration légitime atteint une limite configurée, identifiez la limite exacte et consultez les valeurs documentées pour votre version de Synapse. Envisagez de répartir la charge de requêtes dans le temps. Modifiez une valeur pertinente à la fois, conservez la configuration précédente et surveillez les taux d’erreur et l’utilisation des ressources après le rechargement ou le redémarrage, selon les besoins de votre déploiement.

Référence : Configuration de Synapse :rc_joins et Configuration de Synapse :rc_joins_per_room . Les valeurs par défaut et les options prises en charge peuvent varier selon la version ; comparez-les avec votre version installée avant toute modification.

Utilisez un test de jointure contrôlé

1. Choisissez une salle concernée et notez son alias ou son identifiant, le serveur d'origine de l'utilisateur qui s'y connecte, l'heure et l'erreur client exacte. N'incluez jamais les jetons d'accès dans un journal d'assistance.
2. Vérifiez le testeur de fédération pour le nom de votre serveur et confirmez le point de terminaison de fédération configuré, le certificat et la route proxy.
3. Consultez les journaux Synapse autour de cet horodatage pour détecter les échecs de fédération, les erreurs de destination distante, les délais d'attente ou les réponses de limitation de débit. Recherchez des délais similaires dans les journaux du proxy inverse et de la base de données.
4. Consultez l'API d'administration de la fédération pour connaître l'état de nouvelle tentative associé aux destinations distantes concernées. Comparez les salles affectées avec une salle témoin qui se connecte rapidement.
5. Comparez les métriques de Prometheus et de l'hôte sur la même période. Surveillez toute augmentation de la latence des requêtes, de la durée des transactions de base de données, de l'utilisation du processeur ou de la mémoire, ou tout pic d'activité de fédération.
6. Effectuez une correction ciblée (par exemple, la résolution d'un problème DNS/TLS/proxy, la résolution d'un goulot d'étranglement de base de données ou l'ajustement d'une contrainte de limite de débit confirmée), puis répétez le même test et comparez les résultats.

Hypothèses courantes à éviter

• « Une connexion lente signifie que le port 8448 de mon serveur est fermé. » Pas nécessairement. La délégation ou un proxy inverse peuvent utiliser le port 443. Vérifiez le point de terminaison de fédération configuré et testez-le.
• « Un test de fédération réussi garantit la rapidité de chaque connexion à une salle. » Ce test vérifie uniquement la configuration et la connectivité de fédération courantes. L’état du serveur distant, l’état de la salle, la charge locale et les performances de la base de données peuvent toujours affecter une connexion. Testez la salle concernée et consultez les journaux.
• « Le délai de fédération provient toujours de mon instance Synapse. » La documentation de configuration de Synapse indique que ce délai peut provenir de l'un ou l'autre point d'extrémité, ou du réseau qui les relie. Comparez les destinations et, si possible, recueillez des preuves aux deux extrémités.
• « Ajouter des ressources ou augmenter les limites de débit est une première solution. » Ces modifications ne sont utiles que si les mesures indiquent un problème de capacité ou de limitation de débit. Il faut d'abord déterminer si le problème provient de la connectivité, des tentatives de connexion à distance, de la saturation locale, de la latence de la base de données ou de la limitation du nombre de connexions.

Vérifiez que la correction a fonctionné

Répétez le même test d'association après la modification. Vérifiez que l'utilisateur s'associe correctement, que la destination concernée ne rencontre plus d'échecs répétés, que l'outil de test de fédération signale correctement les vérifications pertinentes et que la latence des requêtes/de la base de données revient à la normale. Surveillez toute récurrence du problème lors d'une période de forte activité ultérieure ; une tentative réussie ne garantit pas le bon fonctionnement du serveur distant ou du réseau.

Si vos indicateurs locaux et vos contrôles de fédération sont corrects, mais qu'un seul serveur distant continue de rencontrer des problèmes, communiquez l'horodatage, la destination, l'erreur anonymisée et les identifiants de requête pertinents aux administrateurs de ce serveur. Si plusieurs salles et destinations sont affectées, et que les requêtes locales sont lentes, examinez la capacité de Synapse et de PostgreSQL avant de modifier le comportement de la fédération. Indiquez votre version de Synapse dans les notes d'incident, car la configuration et les détails de l'API d'administration peuvent évoluer.