Project

General

Profile

Development #80613

Revoir le stockage et la gestion des "visited_object"

Added by Pierre Ducroquet about 1 year ago. Updated about 1 year ago.

Status:
Fermé
Priority:
Haut
Target version:
-
Start date:
28 August 2023
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

Actuellement, l'information sur les visited_object "squatte" le stockage des sessions.
Cela a conduit ce matin à avoir la requête suivante qui a consommé un temps CPU considérable sur le serveur (d'autant plus que nos logs tronquent à 100ms, j'ignore donc le temps réellement utilisé en permanence par cette requête)

select id, session_data from sessions where last_update_time >= ?::timestamp; 

Ce qui prend du temps n'est pas le filtrage, mais le décodage côté PG des données pour les renvoyer à l'application, l'encodage réseau, le temps réseau, puis le temps de décodage côté applicatif. Par ailleurs, autre facteur à prendre en compte : le stockage dans le session_data, un bytea contenant un objet pickle, est particulièrement inefficace à la mise à jour puisque le code python doit tout reconstruire, et cela fait des enregistrements particulièrement volumineux pour peu de données utiles.

J'ai identifié le code suivant comme fort possiblement responsable de cet appel:

pierre@entrouvert-pierred:~/eo/wcs$ git grep select_recent
wcs/sessions.py:        for session in cls.select_recent(ignore_errors=True):
wcs/sessions.py:        for session in self.__class__.select_recent(ignore_errors=True):
wcs/sql.py:    def select_recent(cls, seconds=30 * 60, **kwargs):

Cela correspond aux méthodes Session::get_visited_objects et Session::unmark_visited_object.
La seconde prend en paramètre un formdata, elle sait donc quel objet doit être retiré. Un stockage efficace doit prendre en compte ce besoin.
La première renvoie une liste de tous les objets visités, en en excluant éventuellement un utilisateur.

Je suggère de remplacer tout ceci par une table "visited_object" (quelle imagination) avec la définition suivante:

CREATE TABLE visited_object (
  object_key character varying not null,
  visit_timestamp timestamp with time zone not null,
  visitor integer
);

Je n'ai pas l'impression que l'on puisse imposer une unicité au sein de cette table (et inutile de créer une fausse clé primaire sans intérêt).


Related issues

Related to w.c.s. - Development #81183: Revoir le stockage et la gestion des "visited_object"En cours28 August 2023

Actions

Associated revisions

Revision 9820b21d (diff)
Added by Pierre Ducroquet about 1 year ago

session: limit visited objects in db query to sessions with visited objects (#80613)

Instead of fetching all recent sessions, fetch only the sessions with a
visited object, providing a great optimization even without any index.
The time is currently spent in de-toasting, formatting for the PG protocol,
and deparsing and unpickling on Python side, all for nothing for most
sessions.

Revision 0a7eb350 (diff)
Added by Pierre Ducroquet about 1 year ago

session: limit visited objects in db query to sessions with visited objects (#80613)

Instead of fetching all recent sessions, fetch only the sessions with a
visited object, providing a great optimization even without any index.
The time is currently spent in de-toasting, formatting for the PG protocol,
and deparsing and unpickling on Python side, all for nothing for most
sessions.

History

#1

Updated by Pierre Ducroquet about 1 year ago

Option pour l'unicité :

CREATE TABLE visited_object (
  object_key character varying not null,
  visit_timestamp timestamp with time zone not null,
  visitors integer[],
  primary key(object_key)
);

#3

Updated by Robot Gitea about 1 year ago

  • Status changed from Nouveau to En cours
  • Assignee set to Pierre Ducroquet

Pierre Ducroquet (pducroquet) a ouvert une pull request sur Gitea concernant cette demande :

#4

Updated by Pierre Ducroquet about 1 year ago

  • Assignee changed from Pierre Ducroquet to Mikaël Ates

Limite à cette proposition, que je ne voyais pas en lisant simplement le code des sessions : les tests unitaires "s'attendent" à ce que les visites soient au moins partiellement liées à une session au lieu d'un utilisateur. Si c'est bien le cas, il faut alors rajouter un session_id sur la table, mais j'aimerais avoir confirmation de ce fait avant de procéder.

#5

Updated by Benjamin Dauvergne about 1 year ago

  • Assignee changed from Mikaël Ates to Frédéric Péters
#6

Updated by Robot Gitea about 1 year ago

  • Assignee changed from Frédéric Péters to Pierre Ducroquet

Pierre Ducroquet (pducroquet) a ouvert une pull request sur Gitea concernant cette demande :

#7

Updated by Pierre Ducroquet about 1 year ago

La seconde pull request correspond à une optimisation assez basique que j'ai remarqué en faisant la réécriture précédente. Il faudrait a minima intégrer ce changement pour avoir déjà pas mal de bénéfices sur les appels concernés.

#8

Updated by Robot Gitea about 1 year ago

  • Status changed from En cours to Solution proposée
#9

Updated by Robot Gitea about 1 year ago

  • Status changed from Solution proposée to Solution validée

Frédéric Péters (fpeters) a approuvé une pull request sur Gitea concernant cette demande :

#10

Updated by Robot Gitea about 1 year ago

  • Status changed from Solution validée to Résolu (à déployer)

Pierre Ducroquet (pducroquet) a mergé une pull request sur Gitea concernant cette demande :

#11

Updated by Transition automatique about 1 year ago

  • Status changed from Résolu (à déployer) to Solution déployée
#12

Updated by Pierre Ducroquet about 1 year ago

  • Status changed from Solution déployée to En cours

Ce qui a été intégré correspond à une optimisation pour réduire l'importance de ce correctif, mais ne l'évite pas.

#13

Updated by Frédéric Péters about 1 year ago

  • Related to Development #81183: Revoir le stockage et la gestion des "visited_object" added
#14

Updated by Frédéric Péters about 1 year ago

  • Status changed from En cours to Fermé

Ce qui a été intégré correspond à une optimisation pour réduire l'importance de ce correctif, mais ne l'évite pas.

Je ferme ici pour garder une association claire entre commits et tickets, j'ai copié vers #81183 pour la suite.

#15

Updated by Robot Gitea about 1 year ago

Pierre Ducroquet (pducroquet) a commencé à travailler sur une pull request sur Gitea concernant cette demande :

Also available in: Atom PDF