Performance du calcul des créneaux de disponibilités

[DanteZ5]

Actuellement

• l'accès aux créneaux de disponibilités génère des temps de chargement trop longs
• https://www.skylight.io/app/applications/RgR7i58P67xN/1665352800/1d/endpoints/Admin::SlotsController%23index?responseType=html

Objectif

• réduire ces temps de chargement afin
  • d'améliorer l'expérience utilisateur actuelle
  • d'anticiper les appels API par les services externes sur ces créneaux

Technique

• le calcul des créneaux se fait au niveau du service : SlotBuilder
• plusieurs hypothèses de ralentissement sont émises :
  • les créneaux n'étant pas stockés, on manipule des objets (pas de requêtes)
  • la superposition de plusieurs plages d'ouvertures multiplie le temps de chargement
  • le calcul du prochain créneau disponible s'appuie sur la méthode (déjà lente) de calcul de l'ensemble des créneaux disponibles et peut être rappelé ensuite

1ère hypothèse d'amélioration : stocker en base des objets de disponibilités (par exemple : Disponibilite)

• piste de perdre de la perf en écriture pour en gagner en lecture
• identifier ce qu'ils stockent comme info (start_at, end_at + toutes les relations nécessaires)
• isoler les écritures, mises à jour, suppression de ces objets via des jobs
• identifier les callbacks d'écriture, mise à jour, suppression de ces objets.
• Est ce du callback unitaire ou un algo plus conséquent qui vérifie l'ensemble de la structure de DB en récurrence ?

2nde hypothèse (moins structurante) : isoler le calcul du prochain créneau

• on ne résoud qu'une partie du problème, mais probablement moins complexe

3ème hypothèse (écartée ou optionnelle) : mettre en cache le calcul

• hypothèse écartée actuellement car il est préférable d'isoler le calcul du prochain créneau et de processer le calcul qu'à la demande d'un usager.
• le cache n'est pas forcément inutile pour prévenir des raffraichissements provoqués par l'utilisateur, mais ne résoud aussi qu'une partie du problème

[francois-ferrandis]

C'est une belle analyse que tu proposes ici ! Les conclusions de ma dernière investigation étaient :

• Un système de mise en cache des créneaux (ou stockage de valeurs calculées Disponibilite) semble casse-gueule, car l'invalidation de cache c'est dur, même pour des choses moins complexes que ça.
• Parfois il faut accepter qu'une opération est coûteuse, et offrir en première instance une approximation. Dans ce cas, la présence de plage d'ouvertures est une approximation qui permet de déterminer si on a des chances d'avoir des créneaux ou pas du tout (voir PublicLinksController).
• Parfois il faut accepter qu'une opération est coûteuse, et donc l'exécuter à la demande et de façon asynchrone. C'est là un point qui me travaille depuis un moment : quand tu vas sur Doctolib pour chercher un créneaux, les créneaux de chaque lieux sont affichés sur la page de façon asynchrone, au fur et à mesure que tu scrolle. C'est une forme de pagination, dans laquelle le détail de chaque résultat est chargé à la demande. Chez nous, on affiche sur une seule les créneaux pour tous les lieux trouvés, ce qui fait que par exemple si je cherche une vaccination sur Calais, j'ai une page qui met 8 secondes à s'afficher parce que rien n'est paginé. Donc si on arrive à faire en sorte de pouvoir demander les créneaux lieu par lieu, ça ouvre des possibilités d'usages car les performances sont plus acceptables.

Bien sûr, des optimisations de l'algo sont possibles, mais il y a des contournements qui sont potentiellement plus efficace que de complexifier notre code pour les perfs. ;)

[DanteZ5]

échanges avec @damienlethiec : une approche "en douceur" serait de commencer par l'hypothèse 2 : isoler le calcul du prochain créneau ça répondrait à un besoin direct sur certains temps de chargement + un endpoint d'API, même si ça ne répond pas à l'ensemble du besoin. PR réalisable à partir de cette hypothèse

[damienlethiec]

J’ai regardé de mon côté également les possibilités en terme d’amélioration de la perf de la recherche de créneaux. Et j’ai eu l’impression d’ouvrir la boîte de pandore. La situation tech actuelle rend ce calcul vraiment très compliqué. Et même améliorer la perf du calcul du prochain créneau ne serait pas trivial. J’ai donc vite refermé la boîte de pandore. Pour ne pas que cette exploration, même rapide, ne serve à rien, j’aimerais laisser 2 traces:

Tout d’abord, pour faciliter sa compréhension, je veux documenter ici en pseudocode le fonctionnement du service SlotBuilder, que j’ai n’ai pas trouvé si facile à prendre en main. N’hésitez pas à vérifier que je n’écris pas de bétises. Est-ce que ça aurait de la valeur d’intégrer ce pseudo code dans le code ? Ce service a pour but de déterminer les créneaux de rendez-vous disponibles pour un motif et un lieu donné, une liste d’agents donnée et une plage temporelle donnée et à l’exclusion de jours fériés. Son fonctionnement est le suivant:

1. Convertir le range de dates passé en argument en range de datetimes.
2. Déterminer les plages d’ouvertures existantes dans cette range (récurrentes y compris)
3. Convertir chacune de ces plages d’ouverture en range de datetime compatibles avec le range passé en arguments
4. Soustraire à ces ranges les temps occupés par des absences, des jours off ou des rdv déjà pris. A cette étape, on a hash qui associe pour chaque plage d’ouverture un array de ranges
5. Itérer sur l’array de range de chaque plage d’ouverture. Pour chaque range, construire les créneaux accessibles grâce à la durée du motif de rendez-vous. Regrouper tous ces créneaux dans un array et le retourner.

De son côté, la recherche du prochain créneau appelle le SlotBuilder semaine par semaine à partir de la date d’aujourd’hui jusqu’à trouver un créneau ouvert (ou s’arrête au bout de 6 mois)

Ensuite, les options envisagées si on veut vraiment améliorer les perfs (de la plus envisageable à la plus folle):

• Paginer les résultats quand on affiche plusieurs lieux
• Quand pas besoin de la liste précise des créneaux mais juste de savoir s’il y en a ou pas, se contenter d’approximations (si une plage d’ouverture existe, alors il y a sans doute des créneaux)
• Ne jamais afficher les créneaux pour plusieurs lieux ou motifs voire même agents en même temps
• Passer au maximum les appels au SlotBuilder en asynchrone quand c'est possible (s'il y a des endroit où on peut le faire)
• Faire sauter l’étape 2 en utilisant la gem ice_cube qui propose des méthodes pour ça. Mais gros travail et pas dit que ce soit plus rapide que notre méthode custom.
• Ecrire en DB au fil de l’eau les créneaux dispos via des callbacks dès qu’on touche un rdv, une absence ou une plage d’ouverture.
• Ne plus fonctionner en vide mais en plein pour les créneaux. Permettre directement l’écriture des créneaux disponibles en plein. On n’aurait plus besoin pour avoir les créneaux dispos que de faire les créneaux moins les rendez-vous. Voire de modifier les créneaux dès qu’on touche un rdv pour avoir toujours les créneaux à jour. Pour gérer les absences, il faudrait modifier directement les créneaux, avec le choix de le faire sur tous les créneaux de la récurrence ou simplement 1. Il n'y aurait plus d'objet absence en DB. Enorme réécriture, sans doute inenvisageable.

Voilà, quelques pistes. Sans doute pas grand chose à en faire pour l’instant mais au moins on garde une trace de ces réflexions.

[yaf]

J'ajoute ma petite graine.

Je traine l'hypothèse 1 depuis un moment. Nous allons en avoir besoin pour #2515 de toute façon. Cela va permettre de repartir la première partie du calcul (la moitié peut-être ?) sur l'écriture d'objet temporel (indispo, plage d'ouverture, RDV).

Et peut-être qu'il faut faire ça (le ticket #2515 arrive en haut de nos priorités en ce moment sur le médicosocial) avant d'attaquer la construction d'un calcul séparé pour trouver le premier créneau dispo.

[damienlethiec]

J'ai clôturé #2984

Après discussion avec Victor, quelques billes:

• On a encore trop de doutes sur l'impact produit pour les gens. Est-ce qu'ils se limitent aux premiers lieux visibles et dans ce cas une pagination les embêterait peu ? Est-ce qu'il y a des cas d'usage où une latence sur l'apparition des créneaux dû à la durée d'expiration du cache n'est pas acceptable?
• La pagination seule n'est pas suffisante. Même dans le cas où on pagine à la main le next_availability_by_lieux du search_context on est obligé de repasser sur les premiers résultats si on ne cache pas (c'est pas clair mais bon, retenir qu'on a besoin de cache). Et pour l'expiration du cache, soit elle est sacrément complexe, soit le temps d'expiration doit être court et dans ce cas là le gain de perf pas forcément énorme et pose la question de l'impact produit ci-dessus.

Gains de perf créneaux via pagination à reprendre et documenter (cache nécessaire et complexe sauf si faible temps de remise à jour et pas sûr de l’utilisation produit des gens (utilisation pagination ou pas et problème avec cache pas à jour ou pas))