Produits Entr'ouvert » w.c.s.

En interdisant complètement les curseurs coté serveur, on tombe à 3,79s au lieu de 14s (fichier de log log-without-cursor).

Avec des curseurs serveurs à 10000, on est à 3,78s soit dans l'épaisseur du benchmark (fichier de log log-with-cursor-itersize-10000).

Avec une répartition des requêtes sur les tables suivantes (pas bien important pour ce ticket mais c'est intéressant en général) :

1 carddata_11_13ave_direction_traitante
1 formdata_50_contacter_le_departement
1 formdata_50_contacter_le_departement_evolutions
1 sessions
2 carddata_2_13ave_kb_copie
2 users
9 carddata_5_13ave_dispositifs
12 custom_views
85 roles

Dans #54242 qui introduit les curseurs nommés et les connections "isolées", je ne vois pas la justifications des connections isolées, quelle était la raison ?

Benjamin Dauvergne a écrit :

Dans #54242 qui introduit les curseurs nommés et les connections "isolées", je ne vois pas la justifications des connections isolées, quelle était la raison ?

Et je me réponds à moi même, c'est à cause des erreurs "named cursor isn't valid anymore" parce qu'un curseur est attaché à une transaction et qu'on fait des commits un peu n'importe où parce qu'on a pas l'équivalent de atomic() de Django, donc le isolate est important, sauf pour un select(iterator=False), là on est sûr qu'il n'y aura pas de commit pendant le parcours du curseur.

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

Tu pourrais fermer ce ticket et redémarrer un ticket public qui expose brièvement le problème concret ?

Qu'est-ce qui n'est pas concret ? On ne doit pas itérer ligne par ligne ce n'est pas performant, sauf quand c'est nécessaire (faire un select massif sur data_class() ).

La situation précédente était tout charger en mémoire et éclater les serveurs du Grand Lyon. Ce n'était pas "performant".

Ça ne peut donc pas juste être un retour en arrière.

Ici il y a une référence à un ticket privé dont l'intitulé n'a pas de rapport et ça voudrait dire en lire les commentaires pour tenter de peut-être voir de quels objets en quelles circonstances on parle, par exemple, concrètement.

• le premier patch remplace quelques boucles while/fetchone() par des boucles for, parce que ça désactive le chunking qui aurait été précisé au moment de la création du curseur et de plus les boucles ne sont pas très pythonesque. Pour ne pas changer le comportement réel à ce stade je force un .itersize à 1 au moment de la création d'un curseur nommé.
• le deuxième patch limite _iterate_on_server aux cas où c'est nécessaire, i.e. on utilise vraiment un générateur dans le code de w.c.s et pas simplement pour remplir une liste qui sera renvoyée;
• le troisième pose un .itersize plus raisonnable de 2000 en général (c'est de toute façon la valeur par défaut dans psycopg2, si on utilise pas fetchone() ou fetchmany() explicitement) et de 100 pour les formulaires et les fiches, ça peut s'affiner ou bien revenir à une valeur plus faible pour toute le monde, ça n'a pas d'effet sans le premier patch, je pourrai merger les deux.

Apparemment c'est cette version qui crashait donc non.

Ce n'est pas la bonne approche, sans pouvoir déterminer le début et la fin d'une transaction on ne peut pas utiliser des curseurs nommés correctement et donc revenir à une connexion par requête comme en Django. Il faudrait un patch qui remplace tous les conn.commit()/.rollback() explicites par l'utilisation d'un context manager comme atomic() en Django (et par défaut que la connexion soit en mode autocommit, c'est beaucoup plus simple à gérer). J'ouvrirai un autre ticket avec cette idée, je garde le lien vers la trace sous le coude.

PS: Le problème existe aussi en Django, il est juste plus difficile de tomber dedans, mais avec un code de cette forme on peut y arriver :

with atomic():
     iterator = Model.objects.iterator()

for instance in interator: <-- normalement une DatabaseError "named cursor isn't valid anymore" 
   ...