Heureusement, cela ne signifie généralement pas cela.
La variable manquante dans votre équation est la façon dont votre base de données et votre serveur d'application et tout autre élément de votre pile gère la la simultanéité .
Pour illustrer cela strictement du point de vue de MySQL, j'ai écrit un programme client de test qui établit un nombre fixe de connexions au serveur MySQL, chacune dans son propre thread (et donc, capable d'émettre une requête vers le serveur à peu près au même moment) .
Une fois que tous les threads ont signalé qu'ils étaient connectés, un message leur est envoyé à tous en même temps pour envoyer leur requête.
Lorsque chaque thread reçoit le signal "go", il regarde l'heure système actuelle, puis envoie la requête au serveur. Lorsqu'il reçoit la réponse, il examine à nouveau l'heure du système, puis renvoie toutes les informations au thread principal, qui compare les horaires et génère la sortie ci-dessous.
Le programme est écrit de telle manière qu'il ne compte pas le temps nécessaire pour établir les connexions au serveur, car dans une application qui se comporte bien, les connexions seraient réutilisables.
La requête était SELECT SQL_NO_CACHE COUNT(1) FROM ... (une table InnoDB contenant environ 500 lignes).
threads 1 min 0.001089 max 0.001089 avg 0.001089 total runtime 0.001089
threads 2 min 0.001200 max 0.002951 avg 0.002076 total runtime 0.003106
threads 4 min 0.000987 max 0.001432 avg 0.001176 total runtime 0.001677
threads 8 min 0.001110 max 0.002789 avg 0.001894 total runtime 0.003796
threads 16 min 0.001222 max 0.005142 avg 0.002707 total runtime 0.005591
threads 32 min 0.001187 max 0.010924 avg 0.003786 total runtime 0.014812
threads 64 min 0.001209 max 0.014941 avg 0.005586 total runtime 0.019841
Les temps sont en secondes. Les min/max/moy sont les meilleurs/pires/moyens temps observés en exécutant la même requête. À une simultanéité de 64, vous remarquez que le meilleur des cas n'était pas si différent du meilleur des cas avec une seule requête. Mais le plus gros point à retenir ici est la colonne d'exécution totale. Cette valeur est la différence de temps entre le moment où le premier thread a envoyé sa requête (ils envoient tous leur requête essentiellement au même moment, mais "précisément" au même moment est impossible car je n'ai pas de machine à 64 cœurs pour exécuter le test script on) jusqu'au moment où le dernier thread a reçu sa réponse.
Observations :la bonne nouvelle est que les 64 requêtes prenant en moyenne 0,005586 secondes n'ont certainement pas nécessité 64 * 0,005586 secondes =0,357504 secondes pour s'exécuter... elles n'ont même pas nécessité 64 * 0,001089 (le meilleur temps) =0,069696 Tous de ces requêtes ont été lancées et terminées en 0,019841 seconde... ou seulement environ 28,5 % du temps qu'il leur aurait théoriquement fallu pour s'exécuter l'une après l'autre.
La mauvaise nouvelle, bien sûr, est que le temps d'exécution moyen de cette requête à une simultanéité de 64 est plus de 5 fois plus élevé que le temps où elle n'est exécutée qu'une seule fois... et le pire des cas est presque 14 fois plus élevé. Mais c'est encore bien mieux que ne le suggère une extrapolation linéaire à partir du temps d'exécution d'une seule requête.
Les choses ne s'échelonnent pas indéfiniment, cependant. Comme vous pouvez le voir, les performances se détériorent avec la simultanéité et à un moment donné, elles se dégradent - probablement assez rapidement - lorsque nous atteignons le premier goulot d'étranglement. Le nombre de tables, la nature des requêtes, tout verrouillage rencontré, tout cela contribue à la façon dont le serveur fonctionne sous des charges simultanées, tout comme les performances de votre stockage, la taille, les performances et l'architecture, la mémoire du système et les composants internes de MySQL - dont certains peuvent être réglés et d'autres non.
Mais bien sûr, la base de données n'est pas le seul facteur. La façon dont le serveur d'applications gère les requêtes simultanées peut être une autre partie importante de vos performances sous charge, parfois dans une plus grande mesure que la base de données, et parfois moins.
Une grande inconnue de vos benchmarks est le temps passé par la base de données à répondre aux requêtes, le temps passé par le serveur d'application à exécuter l'activité logique et le temps passé par le code qui est rendre les résultats de la page en HTML.
