Som tur är brukar det inte betyda det.
Den saknade variabeln i din ekvation är hur din databas och din applikationsserver och allt annat i din stack hanterar samtidighet .
För att illustrera detta strikt ur MySQL-perspektivet skrev jag ett testklientprogram som upprättar ett fast antal anslutningar till MySQL-servern, var och en i sin egen tråd (och så kan skicka en fråga till servern ungefär samtidigt) .
När alla trådar har signalerat tillbaka att de är anslutna, skickas ett meddelande till dem alla samtidigt för att skicka deras fråga.
När varje tråd får "gå"-signalen tittar den på den aktuella systemtiden och skickar sedan frågan till servern. När den får svaret tittar den på systemets tid igen och skickar sedan all information tillbaka till huvudtråden, som jämför tiderna och genererar utdata nedan.
Programmet är skrivet på ett sådant sätt att det inte räknar tiden som krävs för att upprätta anslutningarna till servern, eftersom anslutningarna i en väluppfostrad applikation skulle kunna återanvändas.
Frågan var SELECT SQL_NO_CACHE COUNT(1) FROM ... (en InnoDB-tabell med cirka 500 rader 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
Tiderna är i sekunder. Min/max/avg är de bästa/sämsta/genomsnittliga tiderna som observerats när samma fråga körs. Vid en samtidighet av 64 märker du att det bästa fallet inte var så annorlunda än det bästa fallet med bara en fråga. Men största take-away här är kolumnen för total körtid. Det värdet är skillnaden i tid från när den första tråden skickade sin fråga (de skickar alla sin fråga i princip samtidigt, men "precis" samma tidpunkt är omöjligt eftersom jag inte har en 64-kärnig maskin att köra testskript på) till när den sista tråden fick sitt svar.
Observationer:den goda nyheten är att de 64 frågorna som tog ett genomsnitt på 0,005586 sekunder definitivt inte krävde 64 * 0,005586 sekunder =0,357504 sekunder att köra... det krävde inte ens 64 * 0,001089 (bästa fallet tid) =696069. av dessa frågor startades och avslutades inom 0,019841 sekunder... eller bara cirka 28,5 % av tiden som det teoretiskt skulle ha tagit för dem att köra en efter en.
De dåliga nyheterna är förstås att den genomsnittliga exekveringstiden för denna fråga vid en samtidighet av 64 är över 5 gånger så hög som den tid då den bara körs en gång... och det värsta fallet är nästan 14 gånger så hög. Men det är fortfarande mycket bättre än en linjär extrapolering från exekveringstiden för en enda fråga skulle antyda.
Saker skalar inte på obestämd tid, dock. Som du kan se försämras prestandan samtidigt och någon gång skulle det gå nedförsbacke – förmodligen ganska snabbt – när vi nådde den flaskhals som inträffade först. Antalet tabeller, frågornas karaktär, eventuella låsningar som påträffas, alla bidrar till hur servern presterar under samtidiga belastningar, liksom prestandan för din lagring, storleken, prestanda och arkitektur, av systemets minne, och det interna i MySQL -- av vilka en del kan ställas in och en del inte.
Men databasen är naturligtvis inte den enda faktorn. Sättet som applikationsservern hanterar samtidiga förfrågningar kan vara en annan stor del av din prestanda under belastning, ibland i större utsträckning än databasen, och ibland mindre.
En stor okänd från dina riktmärken är hur mycket av den tiden som spenderas av databasen på att svara på frågorna, hur mycket av tiden spenderas av applikationsservern som kör logikverksamheten och hur mycket av tiden spenderas av koden som är rendera sidresultaten till HTML.