Esta es una pregunta canónica sobre la planificación de capacidad para sitios web.
Relacionado:
¿Cuáles son algunas herramientas y métodos recomendados de planificación de capacidad para sitios web y aplicaciones web?
No dude en describir diferentes herramientas y técnicas para diferentes servidores web, marcos, etc., así como las mejores prácticas que se aplican a los servidores web en general.
Respuestas:
La respuesta corta es: Nadie puede responder esta pregunta excepto usted.
La respuesta larga es que la evaluación comparativa de su carga de trabajo específica es algo que necesita realizar usted mismo, porque es un poco como preguntar "¿Cuánto dura un trozo de cuerda?".
Un simple sitio web estático de una página podría estar alojado en un Pentium Pro 150 y aún así servir miles de impresiones todos los días.
El enfoque básico que debe tomar para responder esta pregunta es probarlo y ver qué sucede. Hay muchas herramientas que puede usar para presionar artificialmente su sistema para ver dónde se dobla.
Una breve descripción de esto es:
Básicamente, para probar algo de carga, necesitas algo contra lo que probar. Configure un entorno para probar. Si es posible, esto debería ser una suposición bastante cercana a su hardware de producción, de lo contrario, se quedará extrapolando sus datos.
Configure sus servidores, cuentas, sitios web, ancho de banda, etc. Incluso si lo hace en máquinas virtuales, está bien siempre que esté preparado para escalar sus resultados.
Entonces, voy a configurar una máquina virtual de potencia media (dos núcleos, 512 MB de RAM, 4 GB de disco duro) e instalar mi equilibrador de carga favorito, haproxydentro de Red Hat Linux en la VM.
También voy a tener dos servidores web detrás del balanceador de carga que voy a usar para probar el balanceador de carga. Estos dos servidores web están configurados de manera idéntica para mis sistemas en vivo.
Necesitará algunas métricas para monitorear, así que voy a medir cuántas solicitudes llegan a mis servidores web y cuántas solicitudes puedo procesar por segundo antes de que los usuarios comiencen a obtener un tiempo de respuesta de más de dos segundos.
También voy a monitorear el uso de RAM, CPU y disco en la haproxyinstancia para asegurarme de que el equilibrador de carga pueda manejar las conexiones.
Cómo hacerlo depende mucho de sus plataformas y está fuera del alcance de esta respuesta. Es posible que deba revisar los archivos de registro del servidor web, iniciar contadores de rendimiento o confiar en la capacidad de informes de su herramienta de prueba de esfuerzo.
Algunas cosas que siempre quieres monitorear:
También puede optar por mirar puntos muertos de SQL, tiempos de búsqueda, etc., dependiendo de lo que esté probando específicamente.
Aquí es donde las cosas se ponen divertidas. Ahora necesita simular una carga de prueba. Hay muchas herramientas que pueden hacer esto, con opciones configurables:
Elige un número, cualquier número. Digamos que vas a ver cómo responde el sistema con 10,000 visitas por minuto. No importa qué número elijas porque vas a repetir este paso muchas veces, ajustando ese número hacia arriba o hacia abajo para ver cómo responde el sistema.
Idealmente, debe distribuir estas 10,000 solicitudes en múltiples clientes / nodos de prueba de carga para que un solo cliente no se convierta en un cuello de botella de solicitudes. Por ejemplo, las pruebas remotas de JMeter proporcionan una interfaz central desde la cual iniciar varios clientes desde una máquina Jmeter de control.
Presiona el botón mágico Go y observa cómo tus servidores web se derriten y se bloquean.
Entonces, ahora debe volver a las métricas que recopiló en el paso 2. Verá que con 10,000 conexiones simultáneas, su haproxycaja apenas está sudando, pero el tiempo de respuesta con dos servidores web es un toque de más de cinco segundos. Eso no es bueno, recuerde, su tiempo de respuesta apunta a dos segundos. Entonces, necesitamos hacer algunos cambios.
Ahora, necesita acelerar su sitio web más de dos veces. Entonces sabe que necesita ampliar o reducir la escala.
Para escalar, obtenga servidores web más grandes, más RAM, discos más rápidos.
Para escalar, obtenga más servidores.
Use sus métricas del paso 2 y las pruebas para tomar esta decisión. Por ejemplo, si vio que la latencia del disco fue masiva durante la prueba, sabe que necesita escalar y obtener discos duros más rápidos.
Si vio que el procesador estaba al 100% durante la prueba, tal vez necesite escalar para agregar servidores web adicionales para reducir la presión sobre los servidores existentes.
No hay una respuesta genérica correcta o incorrecta, solo hay lo que es correcto para usted. Intente ampliar, y si eso no funciona, escale en su lugar. O no, depende de usted y de algunos que piensan fuera de la caja.
Digamos que vamos a escalar. Así que decido clonar mis dos servidores web (son máquinas virtuales) y ahora tengo cuatro servidores web.
Comience nuevamente desde el Paso 3. Si encuentra que las cosas no van como esperaba (por ejemplo, duplicamos los servidores web, pero los tiempos de respuesta aún son más de dos segundos), busque otros cuellos de botella. Por ejemplo, duplicó los servidores web, pero aún tiene un servidor de base de datos deficiente. O bien, clonó más máquinas virtuales, pero debido a que están en el mismo host físico, solo logró una mayor contención por los recursos de los servidores.
Luego puede usar este procedimiento para probar otras partes del sistema. En lugar de presionar el equilibrador de carga, intente presionar el servidor web directamente o el servidor SQL utilizando una herramienta de evaluación comparativa SQL .
La planificación de la capacidad comienza con la medición, en este caso el tiempo de respuesta frente a la carga. Una vez que sepa el grado en que los programas se ralentizan con la carga, que NO es una función lineal, puede seleccionar un objetivo de tiempo de respuesta y luego descubrir qué recursos se necesitarán para cumplir ese objetivo para una cantidad determinada de carga.
La medición del rendimiento siempre se realiza con unidades de tiempo , como
Cosas como% CPU e IOPS son específicas del sistema, por lo que solo las usará cuando haya planificado el sistema y lo haya medido en preproducción, para que actúe como un "sustituto" de lo que le interesa, el tiempo.
La planificación de la capacidad es una bestia problemática. Es tanto ciencia como arte (si definitivamente es oscuro).
Su mejor caso es que tome decisiones bien informadas y la fortuna / suerte lo favorezca al hacer que la realidad cumpla con sus suposiciones. Si su capacidad necesita suposiciones que coincidan con la realidad, se ve como un yogui místico. Desafortunadamente, si sus suposiciones exceden la realidad, parecerá tener un exceso y un gasto excesivo. Más desafortunadamente, si sus suposiciones están por debajo de la realidad eventual (o son incorrectas), carecerá de la capacidad que necesita y tendrá que luchar para mitigar las fallas de su infraestructura quejumbrosa, lo que hace que parezca que carece de competencia.
Sin presión...
Desafortunadamente, el arte oscuro de la planificación de la capacidad es más de lo que se puede destilar razonablemente en una sola respuesta de Falla del servidor; Realmente, es un tema digno de libros.
Afortunadamente, existe un libro de este tipo: " El arte de planificar la capacidad "
Para ampliar la publicación de Mark Henderson, estoy escribiendo esto específicamente para Apache. Para reiterar lo que dijo: "La respuesta corta es: nadie puede responder a esta pregunta excepto usted". El texto de esta respuesta está tomado en gran medida de mi respuesta a una pregunta similar sobre el rendimiento de un sitio web de Drupal .
Apache es posiblemente uno de los (si no el) servidor web más popular disponible. Es de código abierto y aún se mantiene activamente. Puede ejecutarlo en los sistemas operativos Linux y Windows, pero es más popular en el mundo Linux / Unix.
Usted debe no utilizar un config fuera-de-la-caja de Apache. Siempre necesita sintonizar Apache en su sitio. El archivo de configuración principal de Apache en CentOS se encuentra en /etc/httpd/conf/httpd.conf, y el archivo de configuración principal de Apache en los sistemas Ubuntu generalmente se encuentra en /etc/apache2/apache2.conf. Se utilizan archivos de configuración adicionales para cosas como hosts virtuales .
Al igual que muchos programas, Apache está diseñado para ser flexible y personalizado de acuerdo con las necesidades específicas de un sitio web. Existen diferentes módulos de multiprocesamiento que Apache se puede configurar para usar para unirse a un puerto de red y aceptar y procesar las solicitudes.
La mayoría de las veces en las instalaciones de Apache predeterminadas que vienen con servidores CentOS y Ubuntu, se utiliza el MPM " mod_prefork ". Asumiendo que está utilizando mod_prefork (si no está seguro, entonces es más probable, pero solo usted puede determinarlo). Aquí está lo básico sobre cómo configurarlo:
MaxClients& ServerLimitvariables.Ciertamente, esta no es la respuesta final. Ajustar su servidor Apache lleva tiempo y requiere experiencia para hacerlo bien.