Development #57623
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
Cf. #56562 (c'est un cas super limite, mais de faire les itérateurs coté serveurs coûtent cher, on faire des "FETCH FORWARD 1" avec la latence qui va avec pour chaque ligne de table, le problème est ici aussi que sur un live on initialise quand même
Comme on va de toute façon on va tout charger et retourner tout ça dans une liste, itérer coté serveur ligne par ligne ne sert pas à grand chose (et est plus lent à cause des allers-retours autour de @FETCH FORWARD@).
J'attache un log des requêtes pour le ticket #56562[1], même si je me restreins aux requêtes sur les fiches, histoire de revenir dans un cas plus normal, (pour alimenter les sources de donnée je suppose) on y passe 500ms en 10 requêtes :
<pre>
In [23]: for k in endpoints:
...: print('pid', k, 't0', endpoints[k][0], 't1', endpoints[k][1])
...:
pid 31900 t0 18:09:05.103 t1 18:09:05.189
pid 31901 t0 18:09:05.229 t1 18:09:05.232
pid 31905 t0 18:09:07.213 t1 18:09:07.289
pid 31906 t0 18:09:07.350 t1 18:09:07.353
pid 31907 t0 18:09:07.365 t1 18:09:07.368
pid 31909 t0 18:09:07.401 t1 18:09:07.510
pid 31913 t0 18:09:09.463 t1 18:09:09.538
pid 31914 t0 18:09:09.577 t1 18:09:09.583
pid 31917 t0 18:09:11.532 t1 18:09:11.607
pid 31921 t0 18:09:13.602 t1 18:09:13.673
In [24]: sum
Out[24]: 0.50700000001234 (ms)
</pre>
Il y a certainement un problème aussi avec le nombre de fois où on récupère la liste des vues (12 fois) alors que ça n'est pas du tout utilisé ici (ou alors pour certaines sources de données, mais il n'y a que 2 champs listes dans le formulaire de workflow, on devrait avoir seulement 2 requêtes).
fn1. log des requêtes SQL pour une seule requête à https://demarches-departement13.test.entrouvert.org/backoffice/management/contacter-le-departement/144/live, ça donne 55000 lignes de SQL.
Comme on va de toute façon on va tout charger et retourner tout ça dans une liste, itérer coté serveur ligne par ligne ne sert pas à grand chose (et est plus lent à cause des allers-retours autour de @FETCH FORWARD@).
J'attache un log des requêtes pour le ticket #56562[1], même si je me restreins aux requêtes sur les fiches, histoire de revenir dans un cas plus normal, (pour alimenter les sources de donnée je suppose) on y passe 500ms en 10 requêtes :
<pre>
In [23]: for k in endpoints:
...: print('pid', k, 't0', endpoints[k][0], 't1', endpoints[k][1])
...:
pid 31900 t0 18:09:05.103 t1 18:09:05.189
pid 31901 t0 18:09:05.229 t1 18:09:05.232
pid 31905 t0 18:09:07.213 t1 18:09:07.289
pid 31906 t0 18:09:07.350 t1 18:09:07.353
pid 31907 t0 18:09:07.365 t1 18:09:07.368
pid 31909 t0 18:09:07.401 t1 18:09:07.510
pid 31913 t0 18:09:09.463 t1 18:09:09.538
pid 31914 t0 18:09:09.577 t1 18:09:09.583
pid 31917 t0 18:09:11.532 t1 18:09:11.607
pid 31921 t0 18:09:13.602 t1 18:09:13.673
In [24]: sum
Out[24]: 0.50700000001234 (ms)
</pre>
Il y a certainement un problème aussi avec le nombre de fois où on récupère la liste des vues (12 fois) alors que ça n'est pas du tout utilisé ici (ou alors pour certaines sources de données, mais il n'y a que 2 champs listes dans le formulaire de workflow, on devrait avoir seulement 2 requêtes).
fn1. log des requêtes SQL pour une seule requête à https://demarches-departement13.test.entrouvert.org/backoffice/management/contacter-le-departement/144/live, ça donne 55000 lignes de SQL.