Produits Entr'ouvert » w.c.s.

(copie de #80613 qui a été associé à un autre commit, plus simple, aussi je retire la priorité "haute" vu que ça ne semble plus le cas).

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).