¿Cuáles son las desventajas de velocidad al utilizar varios servidores para servir un sitio web?

¿Cuáles son las desventajas de velocidad al utilizar varios servidores para servir un sitio web?

Sé que estas preguntas son difíciles de responder :) Pero quiero tener una idea del impacto de separar servicios en diferentes servidores.

Específicamente, estoy configurando un sitio web que tendrá un servidor de medios (apache que sirve archivos estáticos), un servidor de aplicaciones (apache que procesa archivos php), un servidor de base de datos maestro y un servidor de base de datos esclavo.

Iba a ejecutar Memcached tanto en los servidores de medios como de aplicaciones como un grupo compartido, pero me preguntaba si sería costoso (en términos de tiempo y recursos) hacerlo. Obviamente, cada vez que se solicita una llamada a Memcached (desde el servidor de aplicaciones), se debe establecer una conexión TCP con el servidor de medios, averiguar dónde están los resultados y luego devolverlos.

Para la configuración de un sitio web pequeño como este, ¿sería mejor aumentar la memoria RAM en el servidor de aplicaciones y NO agrupar la memoria caché entre servidores? ¿O la diferencia es tan pequeña que no vale la pena preocuparse?

Aunque utilicé Memcached como ejemplo, preferiría que las respuestas se mantuvieran bastante genéricas, ya que el mismo escenario podría aplicarse a otros servicios (como una base de datos).

Respuesta1

Si se trata de un sitio web pequeño, creo que este nivel de optimización es excesivo.

Pero hay una forma de saberlo con seguridad:Pruébalo.

Hemos usadoWCATen el pasado para responder preguntas como esta en el pasado. Es una gran herramienta para ver cómo funcionará el sitio bajo diversas cargas.JMetroes otra gran herramienta para algo como esto.

Usando WCAT, por ejemplo, terminamos decidiendo obtener un servidor Hyper-V separado para alojar nuestra VM de base de datos separada de nuestra VM de aplicación web (en este caso, Fogbugz). La prueba demostró que incluso con una cantidad baja de usuarios simultáneos, tener la máquina virtual de base de datos en la misma máquina que la máquina virtual de la aplicación hacía que la aplicación fuera inutilizable (la CPU era el cuello de botella).

Respuesta2

Necesita respuestas a algunas preguntas para responder mejor la suya.

  • ¿Es un único sitio web?
  • ¿Está utilizando recursos intensivos (programación pesada del lado del servidor, transmisión de video, etc.)?
  • ¿Estás usando solo video, db y php/.net?
  • ¿Qué tan bien especificados están los servidores?
  • ¿Qué velocidad tienen los discos duros? ¿Están en una configuración raid?
  • ¿Cuantos procesadores?
  • ¿Cuánta RAM?
  • ¿Está utilizando NIC y conmutadores de 100 MB o 1000 GB?
  • ¿Cuál es su velocidad de subida?
  • ¿Su sistema operativo está optimizado y optimizado?

Respuesta3

No hay suficiente información para dar una respuesta con alguna probabilidad de ser correcta y, de hecho, ejecutar algunas pruebas/puntos de referencia sería la única forma de estar seguro de que está obteniendo la respuesta correcta.

Mi mejor suposición a partir de lo que ha descrito es que la agrupación aumentaría la latencia de una solicitud individual, pero aumentaría la carga agregada que podría manejar antes de que las cosas se estancaran.

Pero cuando digo que sospecho que podría aumentar la latencia de una solicitud individual, me refiero a una cantidad entre una fracción de milisegundo y quizás unas pocas decenas de milisegundos, dependiendo de la configuración de su red. Si su sitio está lo suficientemente ocupado, esto se verá compensado en gran medida por las ventajas de velocidad de realizar menos llamadas a la base de datos con el doble de caché. Si el servidor de medios y el servidor de aplicaciones tienen aproximadamente el mismo hardware, es muy probable que su servidor de aplicaciones obtenga una gran cantidad de uso de CPU y la CPU del servidor de medios estará bastante inactiva, lo que significa que podría obtener el mejor rendimiento usando Memcached solo en el servidor de medios y no el servidor de aplicaciones.

La única forma de estar seguro de una optimización es realizar una prueba. Prueba, punto de referencia, perfil, etc. Sin pruebas, nunca sabrás si estás mejorando o empeorando el rendimiento. Ejecute pruebas de un extremo a otro (en otras palabras, clientes web simulados que realizan todas las solicitudes de archivos que haría un cliente web real) con una combinación realista de usuarios (para obtener la combinación adecuada de aciertos y errores de caché), tanto para moderada cargas y cargas "acabamos de recibir barras y puntos". Automatice su prueba para que sea fácilmente repetible. Pruebe con Memcached en ambos/todos los servidores, solo en un servidor, solo en el otro servidor, con más RAM en un servidor que en el otro, etc...

información relacionada