Development #95095: Optimisation du stockage SQL des sessions - w.c.s. - Redmine Entr’ouvert

Development #95095

Optimisation du stockage SQL des sessions

Added by Pierre Ducroquet 26 days ago. Updated 21 days ago.

Status:

Solution déployée

Priority:

Normal

Assignee:

Frédéric Péters

Target version:

Start date:

09 September 2024

Due date:

% Done:

Estimated time:

Patch proposed:

Planning:

Description

Les sessions sont stockées aujourd'hui avec un bytea session_data, un dictionnaire python stocké en pickle.

Ce stockage perd beaucoup en efficacité pour plusieurs raisons:
- besoin de sérialiser/déserialiser à chaque fois,
- augmentation du volume de données côté PG et sur les échanges réseau,
- impossibilité de filtrer côté SQL certaines colonnes (creation/access time principalement), ce qui ralentit le cron de nettoyage…

À titre d'exemple, le stockage de remote_address, creation_time et access_time prend environ 100 octets en pickle+bytea, 3 à 4 fois plus que ce que cela prendrait en colonnes PG natives. De plus cela réduirait les modifications du champ session_data.

Related issues

Associated revisions

Revision 1a44acb4 (diff)
Added by Frédéric Péters 22 days ago

sql: add more attributes as db columns for sessions (#95095)

Revision 9f9a802f (diff)
Added by Frédéric Péters 22 days ago

misc: keep at most 20 jsonp display values in session (#95095)

History

Updated by Frédéric Péters 25 days ago

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

Updated by Pierre Ducroquet 25 days ago

L'élément qui prend le plus de place dans les sessions sur nimes est le champ jsonp_display_values. Dans le code, je ne vois jamais de ménage de cet élément, ce qui explique donc le volume qu'il prend rapidement. Je pense que ce serait intéressant de le déplacer dans les TransientData.

Updated by Frédéric Péters 25 days ago

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

Je vais regarder ça en prenant cet aspect en compte.

Dans le code, je ne vois jamais de ménage de cet élément

De manière générale sur les sessions on compte sur le fait qu'elles soient supprimées relativement rapidement.

Updated by Frédéric Péters 25 days ago

L'élément qui prend le plus de place dans les sessions sur nimes est le champ jsonp_display_values

Dans certaines sessions uniquement, sur 95878 sessions, il y en a 603 où ça fait plus que 1000 octets. (ça n'empêche bien sûr pas de regarder pour déplacer ça)

Updated by Pierre Ducroquet 25 days ago

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

Frédéric Péters a écrit :

L'élément qui prend le plus de place dans les sessions sur nimes est le champ jsonp_display_values

Dans certaines sessions uniquement, sur 95878 sessions, il y en a 603 où ça fait plus que 1000 octets. (ça n'empêche bien sûr pas de regarder pour déplacer ça)

Le problème c'est surtout les extrêmes, avec des sessions de plus de 150kb.

Updated by Frédéric Péters 25 days ago

Les 3 sessions qui font plus que 100ko (avec ma mesure qui est len(repr(jsonp_display_values))), viennent toutes du même usager (les 6 qui font plus que 50ko pareil, même usager, il faut aller à 25ko pour trouver un autre usager). L'usager c'est un des admins fonctionnels, il doit y avoir un parcours particulier qui alimente beaucoup jsonp_display_values, plutôt que TransientData et ajouter une requête en plus de manière systématique, je me demande si ça vaut plutôt la peine de limiter la taille de jsonp_display_values.

Pierre, pour toi quelle serait la taille max acceptable, en gardant jsonp_display_values dans la table des sessions ?

(pour référence, 10ko sont atteints avec 127 entrées)