Bonjour, Pour faire un retours sur la performance (ou non performance des fetch), voici quelque stats sur un cas rapide sur PostgresSQL, mais très lent sur Sql Server. Le problème de lenteur n'est pas le point ici, mais plutot le volume de données qui transit. Pour la volumétrie de la requete, on a: - 1 Mail (23 champs) - 4 Pièces jointes (9 champs) - 56 Ligne d'historique (7 champs) - 11 autres entité de cardinalité 1 (EtatAttente, DemandStatus...) La requete executée est la suivante: http://forge.codelutin.com/issues/5655#note-3 Elle retourne environ 224 lignes (soit le produit cartésien de 1 * 4 * 56) L'ensemble des champs représente 131 colonne. Soit un ResultSet composé de 29344 élément. Donc 29344 pour afficher un seul élément. À titre de comparaison, la même fonctionnalité en 3 requêtes aurait retourné 1 * 115 = 115 (email + relation 0..1 avec fetch) 4 * 9 = 36 (attachments) 56 * 7 = 392 (historique) Soit un result set de 543 éléments, mais en 3 requetes. Le produit cartésien augmente beaucoup la taille donc je me demande si c'est si performant que ca, ou que cela doit être nuancé par la volumétries des données. Ne faudrait-il pas laisser les fetch pour les relations (0..1) et effectuer d'autres requetes pour les autres relations (2..*) ? -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Merci pour ces chiffres, ça montre bien qu'il faut l'utiliser avec précaution... On 26/08/2014 16:09, Eric Chatellier wrote:
Bonjour,
Pour faire un retours sur la performance (ou non performance des fetch), voici quelque stats sur un cas rapide sur PostgresSQL, mais très lent sur Sql Server. Le problème de lenteur n'est pas le point ici, mais plutot le volume de données qui transit.
Pour la volumétrie de la requete, on a: - 1 Mail (23 champs) - 4 Pièces jointes (9 champs) - 56 Ligne d'historique (7 champs) - 11 autres entité de cardinalité 1 (EtatAttente, DemandStatus...)
La requete executée est la suivante: http://forge.codelutin.com/issues/5655#note-3 Elle retourne environ 224 lignes (soit le produit cartésien de 1 * 4 * 56)
L'ensemble des champs représente 131 colonne. Soit un ResultSet composé de 29344 élément. Donc 29344 pour afficher un seul élément.
À titre de comparaison, la même fonctionnalité en 3 requêtes aurait retourné 1 * 115 = 115 (email + relation 0..1 avec fetch) 4 * 9 = 36 (attachments) 56 * 7 = 392 (historique)
Soit un result set de 543 éléments, mais en 3 requetes.
Le produit cartésien augmente beaucoup la taille donc je me demande si c'est si performant que ca, ou que cela doit être nuancé par la volumétries des données.
Ne faudrait-il pas laisser les fetch pour les relations (0..1) et effectuer d'autres requetes pour les autres relations (2..*) ?
On Tue, 26 Aug 2014 17:49:34 +0200 Arnaud Thimel <thimel@codelutin.com> wrote:
Merci pour ces chiffres, ça montre bien qu'il faut l'utiliser avec précaution...
Pour moi ces seuls chiffres ne suffisent pas, même si ils nous montrent bien un défaut des fetchs. Il faut aussi prendre en compte la coût réseau, je veux dire que lorsque la base n'est pas en local, plus de noeuds réseaux sont traversés, plus les mini requètes sont pénalisantes; je n'ai pas de chiffres à fournir pour le moment, mais j'ai un cas d'utilisation sur ObServe où une opération qui en France prends quelques secondes prend plusieurs dizaines de minutes dans l'océan indien... A suivre :) tony.
On 26/08/2014 16:09, Eric Chatellier wrote:
Bonjour,
Pour faire un retours sur la performance (ou non performance des fetch), voici quelque stats sur un cas rapide sur PostgresSQL, mais très lent sur Sql Server. Le problème de lenteur n'est pas le point ici, mais plutot le volume de données qui transit.
Pour la volumétrie de la requete, on a: - 1 Mail (23 champs) - 4 Pièces jointes (9 champs) - 56 Ligne d'historique (7 champs) - 11 autres entité de cardinalité 1 (EtatAttente, DemandStatus...)
La requete executée est la suivante: http://forge.codelutin.com/issues/5655#note-3 Elle retourne environ 224 lignes (soit le produit cartésien de 1 * 4 * 56)
L'ensemble des champs représente 131 colonne. Soit un ResultSet composé de 29344 élément. Donc 29344 pour afficher un seul élément.
À titre de comparaison, la même fonctionnalité en 3 requêtes aurait retourné 1 * 115 = 115 (email + relation 0..1 avec fetch) 4 * 9 = 36 (attachments) 56 * 7 = 392 (historique)
Soit un result set de 543 éléments, mais en 3 requetes.
Le produit cartésien augmente beaucoup la taille donc je me demande si c'est si performant que ca, ou que cela doit être nuancé par la volumétries des données.
Ne faudrait-il pas laisser les fetch pour les relations (0..1) et effectuer d'autres requetes pour les autres relations (2..*) ?
_______________________________________________ Topia-devel mailing list Topia-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/topia-devel
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit@codelutin.com twitter: https://twitter.com/tchemit
participants (3)
-
Arnaud Thimel -
Eric Chatellier -
Tony Chemit