Produits Entr'ouvert » w.c.s.

C'est peut-être inutilement coûteux en temps sur des sites avec des quantités de formulaires/vues; à mesurer.

Genre presque 10 secondes sur mon site de test qui déborde un peu (une grosse centaine de formulaires).

Ça ira sans doute plus vite une machine qui ne sait que cela, et dimensionnée pour.

Je propose de pousser ce patch.

Patch lancé sur auquo.dev : 30 secondes pour démarrer (le postgresql est en mode debug, mais quand même).

Ça ne va pas. Mais en même temps : #7017...

La piste si ça reste trop long c'est d'avoir également du code de "migration" pour les vues des formdefs.

Sur dev:

$ cat /tmp/wcs-sql-time
https://alfortville.dev.au-quotidien.com (91 formdefs): 1.95542883873s ; 0.021488228997s/formdef
https://imio.dev.au-quotidien.com (11 formdefs): 0.270038127899s ; 0.0245489207181s/formdef
https://vincennes.dev.au-quotidien.com (124 formdefs): 2.36293315887s ; 0.0190559125716s/formdef
https://fsb.dev.au-quotidien.com (5 formdefs): 0.10484790802s ; 0.020969581604s/formdef

On va dire 2 centièmes de secondes par formulaire.

À voir en optimisant un peu postgresql.

Et c'est acceptable d'avoir ces 5 secondes au démarrage ?

Sur la prod, il y a 815 formulaires, ça ferait 16 secondes, ce sera sans doute encore utile d'améliorer les choses.

Joué sur quelques paramètres (zéro log, utilisation max de RAM, etc) : ça ne change pas, la création de vues consomme du temps, on reste à 20ms par formulaire.

C'est nécessaire d'avoir ces vues pour le fonctionnement de w.c.s. ? Dans le cas contraire on pourrait faire ça dans un autre process.

Un truc qui m'étonne c'est que normalement les vues c'est gratuit: il n'y normalement aucun stockage, ni table, ni index, c'est juste des sortes de macro. Je ne vois pas d'où viennent tous ces délais, peut-être la requête est-elle exécutée une première fois pour voir qu'elle fonctionne.

20ms par formulaire ça me fait penser au temps nécessaire pour faire un commit sur disque, peut-être essayer d'accomplir tout cela dans une seule transaction (là j'ai l'impression qu'il y en a une par formdef).

Après réflexion sur le sujet, je reste attaché à l'idée d'exécuter ça au démarrage, qu'on évite des structures de tables/vues qui changent spontanément lors de l'accès à une donnée ou page particulière. Mais mon plan maintenant serait plus simple, plutôt qu'avoir un initialize_sql() servant à la fois à la mise en place initiale des structures et à leurs migrations, je créerais un migrate_sql() et stockerait un "niveau" de SQL, qu'on aurait à manuellement incrémenter en cas de modification incompatible. Si que le niveau connu de sql.py correspond au niveau enregistré dans la base, on ne fait rien; sinon, on peut faire un truc un peu coûteux, sachant que ça n'aura pas lieu à tous les démarrages.

Ack.

Par la suite, on pourrait ajouter une commande "sqlmigrate" à wcsctl (typiquement pour aider à faire un init.d qui détaille le démarrage, qu'on ne soit pas surpris quand ça prendra 15 secondes un jour sur un reboot en prod).