Fortunatamente, di solito non significa questo.
La variabile mancante nella tua equazione è come il tuo database e il tuo server delle applicazioni e qualsiasi altra cosa nel tuo stack gestisce la concurrency .
Per illustrare questo rigorosamente dal punto di vista di MySQL, ho scritto un programma client di prova che stabilisce un numero fisso di connessioni al server MySQL, ciascuna nel proprio thread (e quindi, in grado di inviare una query al server all'incirca nello stesso momento) .
Una volta che tutti i thread hanno segnalato di essere collegati, viene inviato un messaggio a tutti loro contemporaneamente, per inviare la loro richiesta.
Quando ogni thread riceve il segnale "vai", esamina l'ora di sistema corrente, quindi invia la query al server. Quando riceve la risposta, esamina nuovamente l'ora del sistema, quindi invia tutte le informazioni al thread principale, che confronta i tempi e genera l'output di seguito.
Il programma è scritto in modo tale da non contare il tempo necessario per stabilire le connessioni al server, poiché in un'applicazione ben condotta le connessioni sarebbero riutilizzabili.
La query era SELECT SQL_NO_CACHE COUNT(1) FROM ... (una tabella InnoDB con circa 500 righe).
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
I tempi sono in secondi. I tempi min/max/avg sono i tempi migliori/peggiori/medi osservati eseguendo la stessa query. Con una simultaneità di 64, si nota che il caso migliore non era poi così diverso dal caso migliore con una sola query. Ma il più grande take-away qui è la colonna del tempo di esecuzione totale. Quel valore è la differenza di tempo da quando il primo thread ha inviato la sua query (inviano tutti la loro query essenzialmente allo stesso tempo, ma "precisamente" allo stesso tempo è impossibile poiché non ho una macchina a 64 core per eseguire il test script attivato) a quando l'ultimo thread ha ricevuto la sua risposta.
Osservazioni:la buona notizia è che le 64 query che richiedono una media di 0,005586 secondi non hanno sicuramente richiesto 64 * 0,005586 secondi =0,357504 secondi per essere eseguite... non hanno nemmeno richiesto 64 * 0,001089 (il tempo migliore) =0,069696 Tutto di queste query sono state avviate e terminate entro 0,019841 secondi... o solo il 28,5% circa del tempo che sarebbe stato teoricamente necessario per eseguirle una dopo l'altra.
La cattiva notizia, ovviamente, è che il tempo medio di esecuzione di questa query con una simultaneità di 64 è oltre 5 volte più alto del tempo in cui viene eseguito solo una volta... e il caso peggiore è quasi 14 volte più alto. Ma è ancora molto meglio di quanto suggerirebbe un'estrapolazione lineare dal tempo di esecuzione a query singola.
Le cose non scalano indefinitamente, però. Come puoi vedere, le prestazioni si deteriorano con la concorrenza e ad un certo punto andrebbero in discesa, probabilmente abbastanza rapidamente, poiché raggiungevamo il collo di bottiglia che si è verificato per primo. Il numero di tabelle, la natura delle query, qualsiasi blocco che si incontra, contribuiscono tutti alle prestazioni del server sotto carichi simultanei, così come le prestazioni dell'archiviazione, le dimensioni, le prestazioni e l'architettura, della memoria del sistema e gli interni di MySQL, alcuni dei quali possono essere ottimizzati e altri no.
Ma ovviamente, il database non è l'unico fattore. Il modo in cui il server delle applicazioni gestisce le richieste simultanee può essere un'altra parte importante delle tue prestazioni sotto carico, a volte in misura maggiore rispetto al database ea volte meno.
Una grande incognita dai tuoi benchmark è quanto di quel tempo viene speso dal database per rispondere alle query, quanto tempo viene impiegato dal server delle applicazioni per eseguire il business della logica e quanto tempo viene speso dal codice che è rendering dei risultati della pagina in HTML.
