IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

PostgreSQL Discussion :

Temps de réponse à une requête simple


Sujet :

PostgreSQL

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Profil pro
    Inscrit en
    Février 2004
    Messages
    199
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 199
    Par défaut Temps de réponse à une requête simple
    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.

  2. #2
    Membre Expert Avatar de scheu
    Inscrit en
    Juin 2007
    Messages
    1 506
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 1 506
    Par défaut
    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
    La théorie, c'est quand on sait tout mais que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

    Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/

  3. #3
    Membre confirmé
    Profil pro
    Inscrit en
    Février 2004
    Messages
    199
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 199
    Par défaut
    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.

  4. #4
    Membre Expert Avatar de scheu
    Inscrit en
    Juin 2007
    Messages
    1 506
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 1 506
    Par défaut
    Citation Envoyé par subzero82 Voir le message
    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)
    La théorie, c'est quand on sait tout mais que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

    Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/

  5. #5
    Expert éminent
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 741
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 741
    Par défaut heu
    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
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  6. #6
    Membre confirmé
    Profil pro
    Inscrit en
    Février 2004
    Messages
    199
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 199
    Par défaut
    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.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Temps de réponse des requêtes
    Par elharet dans le forum Administration
    Réponses: 5
    Dernier message: 21/11/2008, 16h01
  2. Aide sur une requête simple
    Par Nessie37 dans le forum Requêtes et SQL.
    Réponses: 6
    Dernier message: 21/01/2008, 19h21
  3. Envoyer un fichier audio en réponse à une requète
    Par pathfinder06 dans le forum Développement Web en Java
    Réponses: 4
    Dernier message: 09/11/2007, 09h28
  4. Utilisation du tablespace TEMP lors d'une requête SQL
    Par dyvim dans le forum Administration
    Réponses: 2
    Dernier message: 31/05/2007, 19h15
  5. [Mysql] supprimer redondance dans réponse à une requête
    Par maverick56 dans le forum Langage SQL
    Réponses: 2
    Dernier message: 24/05/2007, 14h29

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo