Por suerte, no suele significar eso.
La variable que falta en su ecuación es cómo su base de datos y su servidor de aplicaciones y cualquier otra cosa en su pila maneja concurrencia .
Para ilustrar esto estrictamente desde la perspectiva de MySQL, escribí un programa cliente de prueba que establece un número fijo de conexiones al servidor MySQL, cada una en su propio subproceso (y, por lo tanto, capaz de emitir una consulta al servidor aproximadamente al mismo tiempo) .
Una vez que todos los subprocesos han indicado que están conectados, se envía un mensaje a todos ellos al mismo tiempo para enviar su consulta.
Cuando cada subproceso recibe la señal de "ir", mira la hora actual del sistema y luego envía la consulta al servidor. Cuando recibe la respuesta, mira la hora del sistema nuevamente y luego envía toda la información al subproceso principal, que compara los tiempos y genera la salida a continuación.
El programa está escrito de tal forma que no cuenta el tiempo necesario para establecer las conexiones con el servidor, ya que en una aplicación con buen comportamiento las conexiones serían reutilizables.
La consulta fue SELECT SQL_NO_CACHE COUNT(1) FROM ... (una tabla InnoDB con alrededor de 500 filas).
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
Los tiempos están en segundos. Min/max/avg son los mejores/peores/tiempos promedio observados al ejecutar la misma consulta. Con una concurrencia de 64, observa que el mejor caso no era tan diferente del mejor caso con solo 1 consulta. Pero lo más importante aquí es la columna de tiempo de ejecución total. Ese valor es la diferencia en el tiempo desde que el primer subproceso envió su consulta (todos envían su consulta esencialmente al mismo tiempo, pero "precisamente" al mismo tiempo es imposible ya que no tengo una máquina de 64 núcleos para ejecutar el script de prueba activado) hasta que el último hilo recibió su respuesta.
Observaciones:la buena noticia es que las 64 consultas que tomaron un promedio de 0.005586 segundos definitivamente no requirieron 64 * 0.005586 segundos =0.357504 segundos para ejecutarse... ni siquiera requirieron 64 * 0.001089 (el mejor tiempo de caso) =0.069696 Todos de esas consultas se iniciaron y finalizaron en 0,019841 segundos... o solo alrededor del 28,5 % del tiempo que, en teoría, habrían tardado en ejecutarse una tras otra.
La mala noticia, por supuesto, es que el tiempo promedio de ejecución de esta consulta con una concurrencia de 64 es más de 5 veces mayor que el tiempo cuando solo se ejecuta una vez... y en el peor de los casos es casi 14 veces mayor. Pero eso sigue siendo mucho mejor de lo que sugeriría una extrapolación lineal del tiempo de ejecución de una sola consulta.
Sin embargo, las cosas no escalan indefinidamente. Como puede ver, el rendimiento se deteriora con la simultaneidad y, en algún momento, iría cuesta abajo, probablemente con bastante rapidez, a medida que llegáramos al cuello de botella que ocurriera primero. La cantidad de tablas, la naturaleza de las consultas, cualquier bloqueo que se encuentre, todo contribuye al rendimiento del servidor bajo cargas simultáneas, al igual que el rendimiento de su almacenamiento, el tamaño, el rendimiento y la arquitectura de la memoria del sistema y las partes internas de MySQL, algunas de las cuales se pueden ajustar y otras no.
Pero, por supuesto, la base de datos no es el único factor. La forma en que el servidor de aplicaciones maneja las solicitudes simultáneas puede ser otra gran parte de su rendimiento bajo carga, a veces en mayor medida que la base de datos y a veces menos.
Una gran incógnita de sus puntos de referencia es cuánto de ese tiempo dedica la base de datos a responder las consultas, cuánto tiempo dedica el servidor de aplicaciones a ejecutar el negocio lógico y cuánto tiempo dedica el código que es renderizar los resultados de la página en HTML.
