ukinoki / Rufus

Rufus est un logiciel open source publié sous licence GPLv3 de gestion d'activité en ophtalmologie et en orthoptie, conçu pour s'adapter à toutes les formes d'exercice : individuel, groupe, et travail multisite. Rufus est bâti sur un modèle client-serveur. Le code est compilable sous MacOSX et Linux. Les exécutables sont téléchargeables sur la page Téléchargements du site.
https://www.rufusvision.org
Other
12 stars 4 forks source link

Accélération de Rufus #12

Closed ukinoki closed 5 years ago

ukinoki commented 6 years ago

- la mise à jour des salles d'attente

​Actuellement, quand un utilisateur change le statut d'un patient (en le faisant passer d'une salle d'attente à son bureau par exemple), il lance la fonction Procedures::UpdVerrouSalDat()_ qui modifie le champ Newidmodifsaldat de la table userconnectes. Toutes les secondes (toutes les 10 secondes en accès distant), sur chaque poste, le timer gTimerSalleDAttente lance la fonction Rufus::VerifSalleDAttente() qui vérifie ce champ et permet de savoir que la salle d'attente a été modifiée. Chaque poste répercute alors cette modification en lançant la fonction _Rufus::RemplirSalDat() qui est une suite de 4 requêtes SQL. Le but est que l'affichage des salles d'attente reste actualisé sur chaque poste. Tant qu'il y a une dizaine de postes connectés, ça va. Mais au delà, si on imagine 60 postes connectés et 60 postes modifiant les salles d'attente 10 à 20 fois par heure, ça fait 600 à 1200 mises à jour de salle d'attente par heure multipliées par 60 postes, soit cette suite de 4 requêtes lancée jusqu'à 72 000 fois par heure, soit 280 000 requêtes, puisqu'il y a 4 requêtes dans la fonction Rufus::Remplir_SalDat() ...

J'ai vérifié. En gros, les 3 premières font 0.002s mais la quatrième fait 0.3s multiplié par 72 000 par heure, 22 000 secondes par heure... No comment. Il faut trouver un autre moyen et je ne sais pas trop comment faire. On peut supprimer la 4ème parce que c'est la moins utile et de très très loin la plus lente (celle qui remplit les patients vus ce jour et qui ont quitté le cabinet - on s'en sert peu et on peut donc ne la faire qu'à la demande soit une à 2 fois par jour par poste...). On passe ainsi à 0.002s x 3 x 72 000, soit 432 secondes par heure, ça redevient humain mais ça fait quand même plus de 7 minutes d'activité du serveur par heure rien que pour mettre à jour les salles d'attente. ​On peut aussi essayer de limiter les modifs aux salles concernées: un patient passe de la salle d'attente à un bureau, on ne remet à jour que ces 2 parties. Actuellement, c'est tout qui est recalculé à chaque fois: bureaux, salle d'attente, accueil et patients vus aujourd'hui. C'est un peu plus coton à modifier mais c'est faisable.

- la liste des patients

Chaque fois qu'un dossier patient est créé ou supprimé, la fonction Procedures::MAJflagPatients() incrémente le champ MAJflagPatients de la table flags. Pareil. Toutes les secondes (toutes les 10 secondes en accès distant), sur chaque poste, le timer gTimerSalleDAttente lance la fonction Rufus::VerifSalleDAttente() qui vérifie ce champ et permet de savoir que la liste des patients a été modifiée et qu'il faut la reconstruire, c'est la fonction _Rufus::Remplir_ListePatientsTableView() qui gère ça. Il y a moins de créations de dossiers - disons 3-4 par médecin et par heure, ce qui fait 120 créations répercutées sur 60 postes soit 7200 fois une grosse requête par heure, 2 fois par seconde.

Là, on est à 0,07s pour 40000 dossiers soit 0.07 x 7200= environ 500 secondes par heure... C'est mieux. Mais s'il y a 400 000 dossiers, ça coincera aussi.

Là non plus, je ne sais pas trop comment faire mais c'est probablement plus simple. Cette mise à jour de la liste des patients n'est utile que si un poste cherche un patient et qu'il doit donc l'afficher dans la liste des patients. Donc ça doit être plus simple à contourner. Par exemple, au lieu de la faire systématiquement, on ne la fait que quand on fait une recherche de patient sur un poste, soit très peu sur les postes soignants ou sur ceux des secrétaires à l'encaissement, qui piochent les patients directement dans les salles d'attente en général. Bref, c'est facile à simplifier et on doit pouvoir facilement diviser ce chiffre par 100. On peut aussi limiter le nombre de résultats à 1000 (c'est ce qui se fait en accès distant) et là on diminue encore beaucoup les temps de réponse.

ukinoki commented 6 years ago

bon, j'ai modifié le recalcul de la liste des patients vus le jour même. Le look de la fiche a changé: la liste n'apparaît et n'est calculée que sur demande et disparait automatiquement au bout de 20 secondes sans interaction avec l'utilisateur. Normalement, on divise par 150 le temps consacré au recalcul des salles d'attente sans titre

ukinoki commented 6 years ago

Suppression de la mise à jour de la liste patients sur chaque poste en cas de création-suppression de dossier. La requête listepatienst n'est donc lancée que sur le poste qui crée ou supprime un dossier et plus sur chaque poste à chaque création-suppression. Si on a 100 postes, elle est donc utilisée 100 fois moins environ.