Tâche #9755
Distribution EOLE - Scénario #9754: Assistance aux utilisateurs (48-49)
étude de problèmes de charge dans le cadre d'un serveur Seshat (SSO PIA/ENT)
Description
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:
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, ...)
Demandes liées
Révisions associées
Optimisations de calcul d'attributs et amélioration du Checker OTP
- Possbilité de mettre en cache les attributs calculés au même titre
que les attributs LDAP (use_cache = True dans les fichiers de calcul) - suppression du stockage du handler PAM dans l'objet Checker OTP.
ref #9755 @1h
données calculées par les attributs 'multi' passées aux fonctions de calcul
- permet de précalculer/mettre en cache un ensemble d'attributs,
et de les écraser au cas par cas dans d'autres fonctions. - en cas de réutilisation de valeurs calculée par un autre attribut,
c'est le nom des fichiers qui détermine l'ordre d'exécution. - affichage du nombre total de sessions dans le log de création
d'une nouvelle session.
ref #9755 @1h
Historique
#1 Mis à jour par Bruno Boiget il y a plus de 9 ans
- Description mis à jour (diff)
#2 Mis à jour par Bruno Boiget il y a plus de 9 ans
- % réalisé changé de 0 à 70
Des paquets de développement ont été mis à disposition pour permettre des optimisations au niveau des attributs calculés.
- Les attributs calculés peuvent désormais être calculés une seule fois à l'ouverture de session et stockés en cache (attributs stables sur la session)
- Christophe est en cours d'optimisation des attributs calculés définis sur leur serveur Seshat. Des fichiers de calcul non utilisés ont été supprimés
- Les résultats des fichiers retournant plusieurs attributs n'étaient pas accessibles aux autres fonctions de calcul (ajoutés en fin
Quelques pistes d'améliorations supplémentaires ont été évoquées:
- Optimiser la récupération du filtre en fonction de l'adresse du service appelant (il y a entre autres beaucoup d'appels à gethostbyname).
- Christophe a évoqué la possibilité de ne lancer certains calculs que si le filtre les nécessite (pas évident pour les fonctions à attributs multiples), à voir une fois les différentes optimisations mises en place.
#3 Mis à jour par Christophe LEON il y a plus de 9 ans
Les actions réalisées ont pu résoudre une partie du problème ( Merci Bruno, pour ton accompagnement)
la demande en l'état peut-être cloturée
La demande suivante #9921 a été créé pour avoir une réflexion plus général sur la mise en cluster de plusieurs SSO
#4 Mis à jour par Bruno Boiget il y a plus de 9 ans
- Statut changé de En cours à Fermé
- % réalisé changé de 70 à 100
- Restant à faire (heures) mis à 0.0