jmtrivial/agenda_culturel
4
4
Fork 0
Code Issues 79 Pull Requests 1 Projects 1 Releases Wiki Activity

optimisation #294

New Issue
Open
opened 2025-01-31 00:58:09 +01:00 by jmtrivial · 4 comments
jmtrivial commented 2025-01-31 00:58:09 +01:00
Owner
Copy Link
  • utiliser defer() ou only() (voire exclude()) sur les vues mois, semaine, upcoming.
  • revoir l'aggrégation par catégorie dans la vue par mois
  • ajouter un cache pour le filtre
  • basculer dans une approche plus dynamique (charger l'interface et les données séparément)
- utiliser defer() ou only() (voire exclude()) sur les vues mois, semaine, upcoming. - revoir l'aggrégation par catégorie dans la vue par mois - ajouter un cache pour le filtre - basculer dans une approche plus dynamique (charger l'interface et les données séparément)
jmtrivial added the
modélisation
 label 2025-01-31 00:58:09 +01:00
jmtrivial changed title from optimisation requêtes to optimisation 2025-01-31 01:11:45 +01:00
jmtrivial commented 2025-01-31 08:59:20 +01:00
Author
Owner
Copy Link
  • regarder l'empreinte mémoire
  • pré-calculer ce qui est possible
  • traiter les cas particuliers (événements récurrents) à part pour alléger le traitement des autres événements
  • ne pas charger ce qui est inutile
  • est-ce qu'on fait 7 requêtes puis traitements plus simples plutôt qu'une seule requête puis répartition dans les jours ?
- regarder l'empreinte mémoire - pré-calculer ce qui est possible - traiter les cas particuliers (événements récurrents) à part pour alléger le traitement des autres événements - ne pas charger ce qui est inutile - est-ce qu'on fait 7 requêtes puis traitements plus simples plutôt qu'une seule requête puis répartition dans les jours ?
jmtrivial referenced this issue from a commit 2025-01-31 20:14:18 +01:00
Petite optimisation
jmtrivial referenced this issue from a commit 2025-01-31 20:14:18 +01:00
Tentatives d'optimisation
jmtrivial referenced this issue from a commit 2025-01-31 20:14:18 +01:00
Optimisation
jmtrivial referenced this issue from a commit 2025-01-31 20:14:18 +01:00
Petites optimisations
jmtrivial commented 2025-02-01 13:22:49 +01:00
Author
Owner
Copy Link

Réflexions sur une approche python+cache+js pour les pages semaine, mois, journées, événements "en même temps":

  • le cache se fait par jour, avec un seul critère: connecté ou non
  • on enregistre en cache une structure de données où tout a été pré-calculé pour chaque événement d'une journée, en plus de ses informations native. Par exemple : l'événement est dupliqué s'il dure plusieurs jours (il apparait dans chaque journée) ou s'il est récurrent, on stocke la distance du lieu à chaque ville pouvant servir au filte, présence d'un TW, texte + lien associé au lieu
  • quand une page est chargée, on lui sert le contenu en cache (est-ce qu'on le transforme en html ou on le laisse en json, à voir)
  • si on l'a livré en json, le javascript ajoute les éléments dans le DOM
  • le javascript filtre les données en ne gardant que les événements correspondant aux critères du filtre
  • si le cache est vieux, au moment de générer la page, le backend demande à celery de mettre à jour le cache
  • si le cache était vieux, le javascript envoie une requête au serveur pour récupérer les versions mises à jour (quand elles seront prêtes)

Mise à jour du cache :

  • le cache a une durée de vie "infinie"
  • À chaque fois qu'on modifie un événement, on demande à celery de refabriquer le cache des jours où il apparaît.
  • À la fin de chaque processus d'import automatique, on met à jour le cache des jours concernés (attention, on ne le fait pas pour chaque événement ajouté)

L'avantage du json :

  • c'est le même pour toutes les pages, donc un seul cache
    L'inconvénient du json :
  • il y a de la génération de html côté client
Réflexions sur une approche python+cache+js pour les pages semaine, mois, journées, événements "en même temps": - le cache se fait par jour, avec un seul critère: connecté ou non - on enregistre en cache une structure de données où tout a été pré-calculé pour chaque événement d'une journée, en plus de ses informations native. Par exemple : l'événement est dupliqué s'il dure plusieurs jours (il apparait dans chaque journée) ou s'il est récurrent, on stocke la distance du lieu à chaque ville pouvant servir au filte, présence d'un TW, texte + lien associé au lieu - quand une page est chargée, on lui sert le contenu en cache (est-ce qu'on le transforme en html ou on le laisse en json, à voir) - si on l'a livré en json, le javascript ajoute les éléments dans le DOM - le javascript filtre les données en ne gardant que les événements correspondant aux critères du filtre - si le cache est vieux, au moment de générer la page, le backend demande à celery de mettre à jour le cache - si le cache était vieux, le javascript envoie une requête au serveur pour récupérer les versions mises à jour (quand elles seront prêtes) Mise à jour du cache : - le cache a une durée de vie "infinie" - À chaque fois qu'on modifie un événement, on demande à celery de refabriquer le cache des jours où il apparaît. - À la fin de chaque processus d'import automatique, on met à jour le cache des jours concernés (attention, on ne le fait pas pour chaque événement ajouté) L'avantage du json : - c'est le même pour toutes les pages, donc un seul cache L'inconvénient du json : - il y a de la génération de html côté client
SebF commented 2025-02-03 07:40:37 +01:00
Collaborator
Copy Link
  • ok pour la granularité du cache à l’évènement, côté transfert j’imagine que c’est le serveur qui compresse pour le transfert ?
  • pour la mise à jour du cache au process d’import automatique, la maille jour c’est par commodité plutôt que d’avoir un flag par évènement ?
  • pour l’inconvénient de la génération html, c’est par principe ou tu as une raison en tête ? (les terminaux sont quand même puissants maintenant)
- ok pour la granularité du cache à l’évènement, côté transfert j’imagine que c’est le serveur qui compresse pour le transfert ? - pour la mise à jour du cache au process d’import automatique, la maille jour c’est par commodité plutôt que d’avoir un flag par évènement ? - pour l’inconvénient de la génération html, c’est par principe ou tu as une raison en tête ? (les terminaux sont quand même puissants maintenant)
jmtrivial commented 2025-02-08 12:58:14 +01:00
Author
Owner
Copy Link

https://ejs.co/ <- utilisé par les amis du temps des cerises, intéressant

https://ejs.co/ <- utilisé par les amis du temps des cerises, intéressant
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
à discuter
architecture
bug
dysfonctionnement à corriger
communication
devops
export
fonctions d'export
importation
processus d'import d'évènements
lieux
gestion des lieux
meta
pour les discussions sur notre organisation interne
modélisation
implique de modifier la modélisation (backend)
modération
gestion de la modération
notification
recherche
concerne la fonctionnalité de recherche
référencement
robot
gestion des robots
source
source d'événements à ajouter à l'agenda pommes de lune
utilisateurs
gestion des utilisateurs
UX
amélioration de l'interface
No Label
modélisation
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: jmtrivial/agenda_culturel#294
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?