Tâche #9755
Mis à jour par Bruno Boiget il y a plus de 9 ans
Christophe Léon m'a contacté par mail concernant des lenteurs du service SSO de leur Seshat académique en période de conseil de classes.
Pour plus de détail, voir la Réponse envoyée en copie à la liste de l'équipe eole.
résulats des tests faits sur un fichier fourni par Christophe:
<pre>
j'ai continué d'enquêter en partant du fichier que tu m'as fourni.
si tu veux avoir une vue plus sympathique des données, tu peux utiliser installer le paquet runsnakerun qui permet d'avoir une représentation visuelle du fichier (runsnake sso.profile, cocher la case 'percent' pour avoir des chiffres plus sympathiques).
avec le fichier que tu m'as fourni, on voit qu'il passe environ 50% du temps à attendre les connexions, le reste est partagé à peu près de cette façon:
- 7% sur les fonctions ssl/crypto
- 5% sur les fonction ldap internes à eolesso (hors attributs calculés)
- 2/3% sur le fonctionnement interne de twisted (gestion de la boucle et des appels tcp)
- le reste (34%) est partagé sur les différentes fonctions du serveur SSO dont :
6% pour les réponses CAS
23% pour les réponses SAML (dont environ 20% dans les différentes fonctions de calcul d'attributs)
Pour optimiser, je vois quelques pistes que l'on pourrait suivre:
* regrouper le plus possible les calculs d'attributs. les fichiers de user_infos peuvent renvoyer un dictionnaire avec plusieurs attributs/valeurs au lieu de seulement une valeur, ça permettrait de limiter les appels à des bases/annuaires externes.
* Les attributs calculés sont recalculés à chaque appel de get_user_details, on pourrait optimiser cette partie en permettant que les valeurs puissent être mises en cache pour la durée de la session (avec possibilité de désactiver ce comportement par attribut).
* j'ai remarqué qu'eole-sso 2.3 utilise un réacteur twisted basé sur 'select'. Les versions plus récentes de twisted utilisent par défaut un réacteur 'epoll', qui est censé mieux réagir avec un nombre important de connexions. Si tu veux tester, il faut ajouter '--reactor epoll' à la fin de DAEMON_OPTIONS dans /etc/init.d/eole-sso (c'est ce qui est utilisé sur Zéphir).
* vérifier si il n'y a pas d'activités suspectes sur le serveur (attaques DDOS, ...)
</pre>
Pour plus de détail, voir la Réponse envoyée en copie à la liste de l'équipe eole.
résulats des tests faits sur un fichier fourni par Christophe:
<pre>
j'ai continué d'enquêter en partant du fichier que tu m'as fourni.
si tu veux avoir une vue plus sympathique des données, tu peux utiliser installer le paquet runsnakerun qui permet d'avoir une représentation visuelle du fichier (runsnake sso.profile, cocher la case 'percent' pour avoir des chiffres plus sympathiques).
avec le fichier que tu m'as fourni, on voit qu'il passe environ 50% du temps à attendre les connexions, le reste est partagé à peu près de cette façon:
- 7% sur les fonctions ssl/crypto
- 5% sur les fonction ldap internes à eolesso (hors attributs calculés)
- 2/3% sur le fonctionnement interne de twisted (gestion de la boucle et des appels tcp)
- le reste (34%) est partagé sur les différentes fonctions du serveur SSO dont :
6% pour les réponses CAS
23% pour les réponses SAML (dont environ 20% dans les différentes fonctions de calcul d'attributs)
Pour optimiser, je vois quelques pistes que l'on pourrait suivre:
* regrouper le plus possible les calculs d'attributs. les fichiers de user_infos peuvent renvoyer un dictionnaire avec plusieurs attributs/valeurs au lieu de seulement une valeur, ça permettrait de limiter les appels à des bases/annuaires externes.
* Les attributs calculés sont recalculés à chaque appel de get_user_details, on pourrait optimiser cette partie en permettant que les valeurs puissent être mises en cache pour la durée de la session (avec possibilité de désactiver ce comportement par attribut).
* j'ai remarqué qu'eole-sso 2.3 utilise un réacteur twisted basé sur 'select'. Les versions plus récentes de twisted utilisent par défaut un réacteur 'epoll', qui est censé mieux réagir avec un nombre important de connexions. Si tu veux tester, il faut ajouter '--reactor epoll' à la fin de DAEMON_OPTIONS dans /etc/init.d/eole-sso (c'est ce qui est utilisé sur Zéphir).
* vérifier si il n'y a pas d'activités suspectes sur le serveur (attaques DDOS, ...)
</pre>