Gelukkig betekent dat meestal niet.
De ontbrekende variabele in uw vergelijking is hoe uw database en uw applicatieserver en al het andere in je stapel verwerkt gelijktijdigheid .
Om dit strikt vanuit het MySQL-perspectief te illustreren, heb ik een testclientprogramma geschreven dat een vast aantal verbindingen met de MySQL-server tot stand brengt, elk in zijn eigen thread (en dus in staat om ongeveer tegelijkertijd een query naar de server te sturen) .
Zodra alle threads hebben gesignaleerd dat ze verbonden zijn, wordt er tegelijkertijd een bericht naar ze verzonden om hun vraag te verzenden.
Wanneer elke thread het "go" -signaal krijgt, kijkt het naar de huidige systeemtijd en stuurt het de vraag naar de server. Wanneer het antwoord krijgt, kijkt het opnieuw naar de systeemtijd en stuurt vervolgens alle informatie terug naar de hoofdthread, die de timings vergelijkt en de onderstaande uitvoer genereert.
Het programma is zo geschreven dat het de tijd die nodig is om de verbindingen met de server tot stand te brengen niet meetelt, aangezien in een goed opgevoede applicatie de verbindingen herbruikbaar zouden zijn.
De zoekopdracht was SELECT SQL_NO_CACHE COUNT(1) FROM ... (een InnoDB-tabel met ongeveer 500 rijen erin).
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
Tijden zijn in seconden. De min/max/avg zijn de beste/slechtste/gemiddelde tijden die zijn waargenomen bij het uitvoeren van dezelfde zoekopdracht. Bij een gelijktijdigheid van 64 merk je dat het beste geval niet zo heel anders was dan het beste geval met slechts 1 zoekopdracht. Maar de grootste take-away hier is de totale runtime-kolom. Die waarde is het verschil in tijd vanaf het moment dat de eerste thread zijn vraag verzond (ze verzenden allemaal hun vraag in wezen op hetzelfde moment, maar "precies" op dezelfde tijd is onmogelijk omdat ik geen 64-core machine heb om de testscript aan) tot wanneer de laatste thread zijn antwoord ontving.
Opmerkingen:het goede nieuws is dat de 64 zoekopdrachten die gemiddeld 0,005586 seconden duren, absoluut geen 64 * 0,005586 seconden =0,357504 seconden nodig hadden om uit te voeren... van die zoekopdrachten werden gestart en beëindigd binnen 0,019841 seconden... of slechts ongeveer 28,5% van de tijd die het theoretisch zou hebben gekost om de een na de ander uit te voeren.
Het slechte nieuws is natuurlijk dat de gemiddelde uitvoeringstijd van deze query bij een gelijktijdigheid van 64 meer dan 5 keer zo hoog is als de tijd dat deze maar één keer wordt uitgevoerd... en in het ergste geval bijna 14 keer zo hoog is. Maar dat is nog steeds veel beter dan een lineaire extrapolatie van de uitvoeringstijd van een enkele query zou suggereren.
Dingen schalen echter niet oneindig. Zoals je kunt zien, verslechteren de prestaties met gelijktijdigheid en op een gegeven moment zou het bergafwaarts gaan - waarschijnlijk vrij snel - als we het knelpunt bereikten dat zich het eerst voordeed. Het aantal tabellen, de aard van de query's, eventuele vergrendeling die wordt aangetroffen, dragen allemaal bij aan hoe de server presteert onder gelijktijdige belasting, evenals de prestaties van uw opslag, de grootte, prestaties en architectuur van het systeemgeheugen, en de binnenkant van MySQL -- waarvan sommige kunnen worden afgestemd en andere niet.
Maar de database is natuurlijk niet de enige factor. De manier waarop de toepassingsserver gelijktijdige verzoeken afhandelt, kan een ander groot deel van uw prestaties onder belasting zijn, soms in grotere mate dan de database en soms minder.
Een grote onbekende van uw benchmarks is hoeveel van die tijd wordt besteed aan het beantwoorden van de query's door de database, hoeveel van de tijd wordt besteed door de applicatieserver die de logische zaken uitvoert en hoeveel van de tijd wordt besteed aan de code die is het weergeven van de paginaresultaten in HTML.