Soupçons de problème de charge

[Éloi Rivard]

@BHoury rapporte que souvent les mercredis entre 13h et 14h le service b3desk ne répond plus. gunicorn ne lève pas d'erreur mais nginx rapporte recv() failed (104: Connection reset by peer)

Sur ce graphique de traffic des load balancer on voit une régularité, mais le jeudi 7 et le vendredi 8 a l'air d'observer plus de traffic que le mercredi 6 mais ne semble pas avoir généré d'erreur. L'erreur ne semble donc pas reproductible à tous les coups.

C'est BBB et non pas B3Desk qui absorbe la charge. Par contre, dans B3Desk, comme il y a beaucoup d'appels synchrones à BBB ou Nextcloud qui peuvent allonger la durée des requêtes, ça pourrait expliquer ce genre de comportements :

b3desk/web/b3desk/routes.py

Lines 292 to 295 in 3632d76

 # TODO: do this asynchroneously 
 # Currently, the page needs to wait another network request in get_meetings_stats 
 # before it can be rendered 
 stats = get_meetings_stats() 

En d'autres termes, si BBB est lent à répondre, alors par effet ricochet B3Desk est long à répondre et les requêtes longues utiliseraient tous les sockets disponibles dans gunicorn, ce qui finit par conduire à un timeout sur nginx. Ça pourrait expliquer aussi pourquoi l'observation de l'erreur ne colle pas à la perfection aux courbes de charge.

[Éloi Rivard]

Visiblement la configuration nginx utilisée à minima sur visio-agents ne permet pas de servir directement les fichiers statiques, et donc rajoute de la charge à gunicorn. Il faudrait utiliser quelque chose comme :

    location = /static {
        root /var/www/html/ ;

        location ~* ^.+\.(?:css|cur|js|jpe?g|gif|htc|ico|png|html|xml|otf|ttf|eot|woff|woff2|svg|webp)$ {
            expires 2d;
            add_header Pragma public;
            add_header Cache-Control "public";
        }
    }

Côté application, nous comptons mettre en cache une partie des résultats des requêtes à l'API BBB avec des outils tels que flask-caching pour permettre de servir les pages plus rapidement.

Nous devons passer en revue le code pour nous assurer qu'aucune requête à nextcloud n'est effectuée lorsque le service est désactivé dans la configuration.

[Loan Robert]

#81

[Klorydryk]

La revue de code concernant les appels à NC lorsque le service est désactivé a-t-il été réalisé ? Est-ce ok de ce point de vue ? Merci.

[Éloi Rivard]

Oui c'est bon, quand les paramètres de configuration relatifs à nextcloud ne sont pas renseignés, aucun appel n'est effectué :

b3desk/web/b3desk/models/users.py

Lines 49 to 58 in 96d0d49

 if ( 
     not current_app.config["NC_LOGIN_API_KEY"] 
     or not current_app.config["NC_LOGIN_API_URL"] 
     or not current_app.config["FILE_SHARING"] 
     or not username 
 ): 
     current_app.logger.debug( 
         "File sharing deactivated or unable to perform, no connection to Nextcloud instance" 
     ) 
     return {"nctoken": None, "nclocator": None, "nclogin": None}