separar el servidor mysql y el servidor web y sus consecuencias

separar el servidor mysql y el servidor web y sus consecuencias

Tengo una aplicación web. Compré un servidor bastante potente para ello. Las especificaciones del servidor se encuentran a continuación: CPU: DUAL E5-2620 RAM: 32 GB DDR3 HDD: 2 x 300 GB SAS 10K Red: Internet de 100 mbps/10 TB.

Especificación del servidor web: Apache/nginx/PHP Base de datos: MySQL

Ahora mis usuarios se drogan día a día. Mi servidor no tolera tal presión. y el tiempo de espera es cada vez mayor. Entonces pensé en separar MySQL y el servidor web en dos servidores idénticos para equilibrar la carga de la CPU. Ahora que descubrí que al separar mysql y php, ¡tendré otros problemas a continuación!

  • Esperando transferencia de red: tengo esta consulta de MySQL: "SELECCIONAR * DE la tabla" Si la tabla tiene más de 500 MB de datos. Con mi velocidad de conexión, tomará varios segundos obtener dicha tabla a través de la red. y es solo para un usuario con una conexión pero se multiplica por 10 conexiones de un usuario y más de 100 usuarios en línea.

El ejemplo anterior es solo un ejemplo, pero los datos reales muestran a continuación información para 100 usuarios en línea al mismo tiempo:

Tráfico + ø + por hora

Recibió+ 14,7 GiB + 201,4 MiB

Enviado+ 429,4 GiB + 5,7 GiB

Total+ 444,2 GiB + 5,9 GiB


Entonces parece que separarse es algo imposible para mi aplicación web. Ahora no sé qué hacer para equilibrar la carga en estos dos servidores sin tener un problema tan grande. ¿Cuál puede ser una forma alternativa de equilibrar la carga de mi CPU sin tener problemas de latencia (al menos con menos problemas)?

*****aviso: la consulta es un ejemplo. Mis consultas están bastante optimizadas, pero mi aplicación es mucho más complicada, por lo que interactúa mucho con la base de datos. Pero la información de MySQL muestra todavía 6GiB de datos transferidos.

Respuesta1

Si optimizó la aplicación web para no utilizar consultas SQL ridículamente ineficientes, probablemente podría volver a colocarlas en el mismo cuadro con una carga mucho menor. No hay ninguna razón por la que todos los usuarios deban leer la tabla completa cada vez. Las consultas e índices adecuados probablemente proporcionarán un enorme impulso aquí, mucho más que simplemente agregarle más hardware.

De lo contrario, ahora fabrican adaptadores Ethernet de hasta al menos 10 Gb/s. Incluso más rápido para algunos de los tipos más exóticos. Un enlace más rápido entre los servidores ayudará. Pero no tanto como las consultas SQL adecuadas.

información relacionada