Heldigvis betyder det normalt ikke det.
Den manglende variabel i din ligning er, hvordan din database og din applikationsserver og alt andet i din stak håndterer samtidighed .
For at illustrere dette strengt set fra MySQL-perspektivet, skrev jeg et testklientprogram, der etablerer et fast antal forbindelser til MySQL-serveren, hver i sin egen tråd (og så kan sende en forespørgsel til serveren på omtrent samme tid) .
Når alle trådene har signaleret tilbage, at de er forbundet, sendes en besked til dem alle på samme tid for at sende deres forespørgsel.
Når hver tråd får "go"-signalet, ser den på det aktuelle systemtidspunkt og sender derefter forespørgslen til serveren. Når den får svaret, ser den på systemets tid igen og sender derefter al information tilbage til hovedtråden, som sammenligner timingen og genererer outputtet nedenfor.
Programmet er skrevet på en sådan måde, at det ikke tæller den tid, det tager at etablere forbindelserne til serveren, da forbindelserne i en velopdragen applikation ville kunne genbruges.
Forespørgslen var SELECT SQL_NO_CACHE COUNT(1) FROM ... (en InnoDB-tabel med omkring 500 rækker i den).
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
Tiderne er i sekunder. Min/maks/gennemsnit er de bedste/værste/gennemsnitlige tider, der er observeret ved at køre den samme forespørgsel. Ved en samtidighed på 64 bemærker du, at den bedste sag ikke var så anderledes end den bedste sag med kun 1 forespørgsel. Men den største take-away her er kolonnen for den samlede runtime. Denne værdi er forskellen i tid fra det tidspunkt, den første tråd sendte sin forespørgsel (de sender alle deres forespørgsel på stort set samme tidspunkt, men "præcis" det samme tidspunkt er umuligt, da jeg ikke har en 64-kerne maskine til at køre test script på) til hvornår den sidste tråd modtog sit svar.
Observationer:den gode nyhed er, at de 64 forespørgsler, der tog et gennemsnit på 0,005586 sekunder, bestemt ikke krævede 64 * 0,005586 sekunder =0,357504 sekunder at udføre... det krævede ikke engang 64 * 0,001089 (den bedste tilfældestid) =696069. af disse forespørgsler blev startet og afsluttet inden for 0,019841 sekunder... eller kun omkring 28,5 % af tiden, det teoretisk ville have taget for dem at køre den ene efter den anden.
Den dårlige nyhed er selvfølgelig, at den gennemsnitlige eksekveringstid på denne forespørgsel ved en samtidighed på 64 er over 5 gange så høj som den tid, hvor den kun køres én gang... og det værste tilfælde er næsten 14 gange så højt. Men det er stadig langt bedre, end en lineær ekstrapolation fra udførelsestiden for en enkelt forespørgsel ville antyde.
Tingene skalerer dog ikke i det uendelige. Som du kan se, forringes ydeevnen samtidig, og på et tidspunkt ville den gå ned ad bakke - sandsynligvis ret hurtigt - efterhånden som vi nåede den flaskehals, der opstod først. Antallet af tabeller, arten af forespørgslerne, enhver låsning, der stødes på, bidrager alt sammen til, hvordan serveren fungerer under samtidige belastninger, ligesom ydeevnen af dit lager, størrelsen, ydeevnen og arkitekturen, af systemets hukommelse og det interne i MySQL -- hvoraf nogle kan tunes, og nogle af dem kan ikke.
Men selvfølgelig er databasen ikke den eneste faktor. Den måde, applikationsserveren håndterer samtidige anmodninger på, kan være en anden stor del af din ydeevne under belastning, nogle gange i større omfang end databasen og nogle gange mindre.
En stor ubekendt fra dine benchmarks er, hvor meget af den tid der bruges af databasen på at besvare forespørgslerne, hvor meget af tiden bruges af applikationsserveren på at udføre logikvirksomheden, og hvor meget af tiden der bruges af koden, der er gengivelse af sideresultaterne til HTML.