La liste patient met, pour les admin, 5,5 secondes à être calculée
Depuis ce matin 10:47:29 (mais pas à chaque fois), juste après les erreurs serveurs.
Ce n'est pas le cas sur dev.
La solution « ça fait 2 semaines qu'on n'a pas rebooté le serveur » n'est pas une solution ;-)
La requête 2 (db.patient.id == db.sequence_file.patient_id) met 0,6 seconde sur le serveur contre 0,1 dans le shell ipython avec web2py chargé…
Quelle différence ? uwsgi ?
Même problème au niveau de la base de données. Cette page mettait plus d'une seconde à charger https://rbx.vidjil.org/vidjil/appadmin/select/db?query=db.patient.id%3E0 contre 0,3 s pour dev
Ça sent le problème côté uwsgi. Mais c'est difficile de faire des tests car modifier le fichier de config entraîne le relancement des process… (et après le relancement, sans modif, le temps de requête est redevenu normal). Peut-être abaisser le max-requests, pour recharger uwsgi plus souvent ? ou vérifier la consommation mémoire de uwsgi ?
En tout cas ce n'est pas satisfaisant. Il ne devrait pas y avoir d'intervention humaine nécessaire.
On vient de passer à 5-7 secondes pour une raison inexpliquée. Du coup on a plein de timeouts. Pourtant rien ne tourne sur le serveur et le réseau est tranquille aussi.
Priorité baissée, ce n'est plus le cas. Mais ça serait bien d'identifier le problème qui a eu lieu…
Ryan, 28 juin:
Je viens de pull une hotfix list patient pour améliorer la lenteur sur prod-server. Faites-moi signe si vous voyez des anomalies :)
J'imagine que tu parles de 1ee80f0. Bravo ! La patient list (pour nous) est passée de 5.5-6.5s à environ 3.5s.
Oui la vitesse n'est pas améliorée pour tout le monde. notament le probleme de lenteur venait du fait que je ne chargeais pas les permissions non présentes (donc quand un utilisateur n'avait pas les permissions anon ou admin sur un patient, une requete bdd était lancée)
Pour mémoire, une manière de logger toutes les requêtes effectuées sur Mysql : http://stackoverflow.com/a/20485975
Aurélie a assez souvent des timeout, en particulier avec la liste patient. En regardant dans les logs, sur les mois de septembre et octobre, la liste patient a mis 5,4s à se charger en moyenne pour elle (n=234, min=2.3, max=11.2, mediane=2.9), et plus de 9s pour 25% des tentatives.
ligne de commande pour avoir la liste des durées pour Aurélie sur sept. et oct :
grep -P '2016-(09|10).*Aurélie.*patient.*list.*s\)\s*$' /var/vidjil/vidjil-debug.log | sed -r 's/^.*\(([0-9.]+)s\)\s*$/\1/'
8177a7de et eb4ab24d On peut s'attendre à des améliorations importantes pour les utilisateurs ayant peu de patients, pas pour les admins. À voir ce que ça change pour Aurélie, une fois en prod.
Comme vu pendant l'audio du jeudi 10/11/2016, une solution de pagniation pourrait être envisagée. Les informations complémentaires pourraient être en 'lazy load' pour réduire la charge. Et nous pourrions ne charger l'entièreté des données d'un utilisateur que lorsqu'un filtre ou un sort est appliqué.
Après quelques tests, en limitant chaque page à 50 patients, mes temps passent de ~1.1s (pour 1130 patients) à ~0.25s