Glücklicherweise bedeutet es das normalerweise nicht.
Die fehlende Variable in Ihrer Gleichung ist, wie Ihre Datenbank und Ihren Anwendungsserver und alles andere in Ihrem Stapel behandelt Parallelität .
Um dies ausschließlich aus der MySQL-Perspektive zu veranschaulichen, habe ich ein Test-Client-Programm geschrieben, das eine feste Anzahl von Verbindungen zum MySQL-Server aufbaut, jede in einem eigenen Thread (und daher in der Lage ist, ungefähr zur gleichen Zeit eine Abfrage an den Server zu stellen). .
Sobald alle Threads signalisiert haben, dass sie verbunden sind, wird eine Nachricht an alle gleichzeitig gesendet, um ihre Anfrage zu senden.
Wenn jeder Thread das "Go"-Signal erhält, sieht er sich die aktuelle Systemzeit an und sendet dann die Abfrage an den Server. Wenn es die Antwort erhält, schaut es erneut auf die Systemzeit und sendet dann alle Informationen zurück an den Haupt-Thread, der die Zeiten vergleicht und die untenstehende Ausgabe generiert.
Das Programm ist so geschrieben, dass es die Zeit, die zum Aufbau der Verbindungen zum Server benötigt wird, nicht mitzählt, da die Verbindungen in einer guten Anwendung wiederverwendbar wären.
Die Abfrage war SELECT SQL_NO_CACHE COUNT(1) FROM ... (eine InnoDB-Tabelle mit etwa 500 Zeilen darin).
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
Die Zeiten sind in Sekunden. Die min/max/avg sind die besten/schlechtesten/durchschnittlichen Zeiten, die bei der Ausführung derselben Abfrage beobachtet wurden. Bei einer Parallelität von 64 stellen Sie fest, dass der beste Fall nicht allzu anders war als der beste Fall mit nur einer Abfrage. Aber der größte Vorteil hier ist die Spalte zur Gesamtlaufzeit. Dieser Wert ist die Zeitdifferenz seit dem ersten Thread, der seine Abfrage gesendet hat (sie senden alle ihre Abfrage im Wesentlichen zur gleichen Zeit, aber "genau" zur gleichen Zeit ist unmöglich, da ich keinen 64-Kern-Computer habe, um dies auszuführen test script on) bis wann der letzte Thread seine Antwort erhalten hat.
Beobachtungen:Die gute Nachricht ist, dass die 64 Abfragen, die durchschnittlich 0,005586 Sekunden dauerten, definitiv nicht 64 * 0,005586 Sekunden =0,357504 Sekunden für die Ausführung benötigten ... es waren nicht einmal 64 * 0,001089 (im besten Fall) =0,069696 erforderlich dieser Abfragen wurden innerhalb von 0,019841 Sekunden gestartet und beendet ... oder nur etwa 28,5 % der Zeit, die theoretisch für eine Ausführung nach der anderen gedauert hätte.
Die schlechte Nachricht ist natürlich, dass die durchschnittliche Ausführungszeit für diese Abfrage bei einer Parallelität von 64 mehr als fünfmal so hoch ist wie bei einer einmaligen Ausführung ... und im schlimmsten Fall fast 14-mal so hoch. Aber das ist immer noch viel besser, als eine lineare Extrapolation aus der Ausführungszeit einer einzelnen Abfrage vermuten lässt.
Die Dinge skalieren jedoch nicht unbegrenzt. Wie Sie sehen können, verschlechtert sich die Leistung mit der Parallelität und irgendwann würde es bergab gehen – wahrscheinlich ziemlich schnell – wenn wir den Engpass erreichten, der zuerst auftrat. Die Anzahl der Tabellen, die Art der Abfragen, alle auftretenden Sperren tragen alle zur Leistung des Servers bei gleichzeitiger Belastung bei, ebenso wie die Leistung Ihres Speichers, die Größe, Leistung und Architektur des Systemspeichers und die Interna von MySQL -- von denen einige angepasst werden können und andere nicht.
Aber natürlich ist die Datenbank nicht der einzige Faktor. Die Art und Weise, wie der Anwendungsserver gleichzeitige Anfragen verarbeitet, kann einen weiteren großen Teil Ihrer Leistung unter Last ausmachen, manchmal in größerem Umfang als die Datenbank und manchmal weniger.
Eine große Unbekannte aus Ihren Benchmarks ist, wie viel Zeit von der Datenbank für die Beantwortung der Abfragen aufgewendet wird, wie viel Zeit von dem Anwendungsserver aufgewendet wird, der das Logikgeschäft ausführt, und wie viel von der Zeit auf den Code verwendet wird Rendern der Seitenergebnisse in HTML.
