Discussion :

[subzero82]

Slt les gars,

Dans le cadre de mon travail, j'ai besoin de mesurer le temps d'exécution d'un bout de code dans lequel je fais appel au serveur de base de données. l'échelle de mesure est à la microseconde pré. J’ai quelques questions à propos du temps de réponse d'un serveur de base de
données.

Soit Q une requête.

1. est-ce qu'un serveur de base de données potgreSQL est capable de répondre avec le même temps de réponse à une même requête Q ?

2. si oui avec quelle granularité ? À la miliseconde pré ? à la microseconde pré ? À la nanoseconde?!!!

3. s’il y' a des variations légères du temps de réponse ; comment y pallier au maximum ?

Merci d'avance pour vos réponses.

[scheu]

Ne le prend pas mal mais ça n'a aucun sens, c'est comme si tu mesurais le temps que Windows mettait à ouvrir Word au millionième de seconde près, tu crois vraiment que ce temps est toujours constant ?

Un degré de précision de l'ordre de la microseconde pour une même requête n'a absolument aucun sens niveau base de données (Postgresql ou autre), pour les raisons suivantes :
- le temps variera toujours de manière presque aléatoirement selon la charge du serveur
- la même requête peut s'exécuter différemment (plan d'exécution)
- les données à récupérer peuvent être en cache mémoire, ce qui signifie que le moteur ne doit pas aller les relire sur disque donc c'est potentiellement plus rapide. Typiquement pour une même requête qui doit lire beaucoup de données, la dexuième exécution et les suivantes sont souvent plus rapides que la première. Mais comme la gestion du cache est une boîte noire, comment veux-tu savoir que telle ou telle donnée est encore en cache ou pas au moment où tu lances la requête ? La quantité de données à relire sur disque est imprévisible donc son temps d'exécution aussi
- les lectures de données sur disque ne prendront jamais toujours le même temps, en fonction de la charge sur les disques
- ... etc ... il y a encore de nombreux paramètres qui peuvent faire varier le temps d'exécution

Tu peux juste avoir le temps d'exécution d'une requête une fois celle-ci exécutée, mais pas avant

Pour des requêtes très rapides, arriver à une précision à la seconde c'est déjà difficile (ex : une même requête peut prend 2s ou 3s ou 4s selon les cas ...)
Pour des longues requêtes, ce serait plutôt une précision à la minute et encore ...

Tu devrais plutôt raisonner en marge d'erreur (exemple : une requête prendra X secondes/minutes plus ou moins 10%) mais là encore c'est empirique, il faut faire des tests et faire des graphes de statistiques (genre courbe de Gauss)

L'informatique n'est pas (toujours) une science extacte et mesurable à la microseconde près

[subzero82]

Merci pour ta réponse.

Même si cela pouvait semblait un peut bizarre , j'avais besoin d'une confirmation par rapport au temps de réponse du serveurs de base de données. je mesurai dans le cadre d'une expérimentation les temps de réponse d'un serveur de base de données à l'échelle de la micro seconde et je me suis retrouvé avec des résultats qui me disais qu'une requête sur un champ ayant un index sur ce dernier pouvait parfois coûtait plus cher que la même requête mais sans l'index sur le champ !!!!

mais bon;

apparemment mon échelle de mesure était trop fine pour démontré quoi que ce soit.

à ton avis à partir de quelle nombre de tuples ou volume pourrais je avoir des données fiables (au moins credible) ? la je fais des mesure sur une base de données qui contient 100 000 tuple dans une seule table.

merci d'avance pour tes remarques.

[scheu]

je me suis retrouvé avec des résultats qui me disais qu'une requête sur un champ ayant un index sur ce dernier pouvait parfois coûtait plus cher que la même requête mais sans l'index sur le champ !!!!

Un index sur une table n'est pas toujours utilisé selon les requêtes s'il est jugé plus coûteux que parcourir la table en entier par exemple, c'est le but de l'optimiseur
Exemple : si tu filtres une grosse table sur une colonne et que que ça doit retourner 90% des lignes, c'est plus rapide de parcourir la table en entier que de passer par l'index pour chaque ligne
Il faut regarder les plans d'exécution pour cela

Sinon 100 000 c'est pas mal, après ça dépend ce que tu veux comparer ou mesurer ... Pour des tests de performances ce n'est pas toujours la volumétrie des tables qui entre en jeu mais aussi la capacité de l'optimiseur de la base à choisir un plan d'exécution correct pour des requêtes complexes avec beaucoup de jointures par exemple
Car sinon un parcours complet simple d'une grosse table revient souvent à mesurer la vitesse du disque qui lit les données (sauf si celles-ci sont en cache)

[wiztricks]

Bonsoir,

Vous pouvez mesurer les temps de réponse à la micro-seconde près.

La question est d'apprécier ce que vous considérez comme "trop lent" et de tolérer que vous ayez un certain pourcentage de requêtes qui excèdent cette valeur (trop lent).

A vous de dire quel doit être la valeur de 'trop lent' et le pourcentage...
Vous pouvez affiner vos exigences en disant "je souhaite que 80% des requêtes répondent en moins de ..."

- W

[subzero82]

Effectivement, après avoir analysé la requête que j'exécute j'ai constaté qu'il faisait un parcours séquentiel de la table au lieu d'utiliser l'index.

Je n'ai pas compris wiztricks ce que tu voulais dire vraiment ; mon problème est de stabiliser le temps de réponse au maximum et non d'avoir une exigence de temps de réponse.

Mes mesures ne sont pas destinées à configurer un serveur pour des fins de productions, mais justes pour des mesures expérimentales destinées à rendre les bases de données (à travers de nouveaux outils, composants et concepts) plus flexibles. Mais plus flexible ne doit pas être au dépend des performances. Il m'est donc nécessaire d'avoir une estimation du surcoût. Des estimations réelles, car comme scheu le soulignait en me taquinant sur la naïveté de ma question : la théorie c'est beau, mais la réalité c'est autre chose.

Donc me voilà à essayer de développer un cadre d'expérimentation adéquat.

[scheu]

A même volumétrie de tables et à charge constante du serveur et de la base, tu peux juste lancer plusieurs fois une même requête, faires des courbes statistiques si ça t'amuses et conclure que "cette requête prend X secondes/minutes plus ou moins n%, c'est tout ... Tu ne pourras jamais être plus précis

[subzero82]

OK, merci

entre temps je me suis amusé avec l'analyseur de requête et j'en ai vue des belles (en fin de compte est les bases de données sont plus bêtes que je ne le pensais).

j'avais mis un index btree sur un champ de TYPE INTEGER (souvenez vous en, j'y viens) et me suis amusé à faire qlq select dessus. du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * FROM table WHERE <champ indéxé> between <a> and <B>

dans le cas ou les deux bornes de la clause between sont des entier l'index est utilisé dans la majorité des cas en particulier pour des select siblés. dans le cas ou l'une des deux borné est un réel un parcours sequentiel est préféré meme pour un select retournant tres peu de ligne !!!! abérant non ???

est ce une conséquence de la méthode d'indéxation que j'a choisi (btree) ? existe il un index capable de prendre en charge cette situation ?

[scheu]

Généralement ce ne sont pas les bases de données qui sont bêtes mais plutôt les développeurs
C'est au développeur à écrire correctement une requête pour que l'optimiseur de la base choisisse le meilleur plan d'exécution
Une requête contenant des conversions de type implicites, ou bien n'utilisant pas les bons types de données, ou bien des fonctions sur des colonnes alors que l'index n'est pas fonctionnel, etc ... ne pourra pas être toujours sauvée par la base de données ...

[subzero82]

t'est un roi scheu .

je devrai laissé tombé un peu la théorie et me concentré sur la réalité .

Merci pour tes explication éclairés.

tu n'aurais par hasard un lien sur une FAQ ou un document qui traite sur l'écriture de requête (les bonnes pratiques) ?

[scheu]

La doc officielle sur le langage SQL pour Postgresql est ton amie, notamment les paragraphes 10, 11 et 13 , ça explique le fonctionnement interne de postgresql et sensibilise les développeurs aux problématiques d'optimisation (choix des indexes, partitionnement, calcul des statistiques, vacuum, plans d'exécution, ...)

[subzero82]

Merci pour aide.