En sous-main, ça génère des requêtes natives. Donc les perfs seront celles de la requête.
Avec, selon le graphique généré, le surcoût "dessin c3js". Lorsqu'on a beaucoup de valeurs à grapher, ça peut être long, mais ce n'est pas à cause de la BD, c'est le coût du dessin.
Et sur le plan produit :
- stocker (et afficher) la durée d'exécution d'un rapport (la dernière fois qu'on l'a exécuté) pour que l'utilisateur puisse voir combien de temps ça prendra d'avoir une réponse
- améliorer quelques comportements pas idéaux (par exemple : un tdb, même s'il a des paramètres, se trace dès qu'on l'ouvre. Il faudrait qu'il ne se trace que lorsque l'utilisateur lui demande, après avoir saisi les paramètres -ou validé sans paramètre-)
- ajouter un "cache résultat", que le créateur du rapport peut activer, en précisant la durée du dit cache. Qui permettra de soulager encore le serveur.
[^] # Re: Sympa comme tout
Posté par Paul POULAIN (site web personnel, Mastodon) . En réponse à la dépêche Publication d’Urungi, tableaux de bord, statistiques, Business Intelligence. Évalué à 4.
En sous-main, ça génère des requêtes natives. Donc les perfs seront celles de la requête.
Avec, selon le graphique généré, le surcoût "dessin c3js". Lorsqu'on a beaucoup de valeurs à grapher, ça peut être long, mais ce n'est pas à cause de la BD, c'est le coût du dessin.
Et sur le plan produit :
- stocker (et afficher) la durée d'exécution d'un rapport (la dernière fois qu'on l'a exécuté) pour que l'utilisateur puisse voir combien de temps ça prendra d'avoir une réponse
- améliorer quelques comportements pas idéaux (par exemple : un tdb, même s'il a des paramètres, se trace dès qu'on l'ouvre. Il faudrait qu'il ne se trace que lorsque l'utilisateur lui demande, après avoir saisi les paramètres -ou validé sans paramètre-)
- ajouter un "cache résultat", que le créateur du rapport peut activer, en précisant la durée du dit cache. Qui permettra de soulager encore le serveur.