Mejores prácticas para resistir el estallido de tráfico en el día de lanzamiento

Question

Estamos trabajando en un sitio web para un cliente que (por una vez) se espera que obtenga una buena cantidad de tráfico el primer día. Hay comunicados de prensa, la gente está blogueando al respecto, etc. Me preocupa un poco que nos caigamos de bruces el primer día. ¿Cuáles son las principales cosas que consideraría para garantizar (de antemano sin datos reales de tráfico) que puede mantenerse en pie después de un gran lanzamiento.

Detalles: Esta es una pila L/A/M/PHP, que utiliza un marco MVC desarrollado internamente. Esto se está lanzando actualmente en un servidor, con Apache y MySQL en él, pero podemos dividirlo si es necesario. Ya estamos instalando memcached y haciendo todo el almacenamiento en caché de PHP que podamos imaginar. Algunas de las páginas son bastante intensivas en consultas, y estamos usando Smarty como nuestro motor de plantillas. Tenga en cuenta que no hay tiempo para cambiar ninguno de estos aspectos principales: esta es la configuración justa. ¿Qué tipo de cosas debemos cuidar?

Answer 1

Para preparar o manejar un rendimiento pico (o pico), primero determinaría si está listo a través de algunas pruebas de rendimiento simple con algo como jmeter.

Es fácil de configurar y comenzar, y le dará las primeras métricas, ya sea que maneje una carga máxima esperada.

Sin embargo, dadas sus limitaciones de tiempo, otros pasos a seguir serían preparar versiones estáticas de contenido que atraerá la mayor atención (como los comunicados de prensa, si es el día de su lanzamiento). También asegúrese de que está haciendo el mejor uso del caché del lado del cliente (una solicitud menos a su servidor puede marcar la diferencia). La web ya diseñada para una escalabilidad extremadamente alta y el almacenamiento en caché de contenido de uso efectivo es su mejor amigo en estas situaciones.

Hay un podcast excelente en alta escalabilidad en software engineering radio on the design of the new Guardian website cuando las cosas se calman.

buena suerte en el lanzamiento

Answer 2

Mida primero, luego optimice. ¿Has hecho alguna prueba de carga? ¿Dónde están los cuellos de botella?

Una vez que conozca sus cuellos de botella, entonces puede decidir inteligentemente si necesita cajas de datos adicionales o cajas de web, en este momento simplemente estaría adivinando.

Además, ¿cómo se comparan los resultados de su prueba de carga con su tráfico esperado? ¿Puedes manejar 2 veces el tráfico esperado? 5x? ¿Qué tan fácil/rápido puede adquirir & liberar hardware adicional? Estoy seguro de que el requisito comercial es no fallar durante el lanzamiento, así que asegúrese de tener lotes de capacidad disponible, siempre puede liberarlo luego cuando la carga se haya estabilizado y sepa lo que necesita.

Answer 3

que había, personalmente, hacer algunas cosas

1) Poner en una especie de equilibrador de carga/sistema de replicación de bases de datos

Esto significa que usted puede tener su propagación servicio a través de múltiples servidores. ¿No puede permitirse tener más de un servidor permanentemente? Utilizar Amazon E3 - Es bueno para la puesta en marcha de este tipo de cosas (interruptor en unos pocos más servidores para manejar la carga)

2) Código de algunas restricciones "alta carga"

Por ejemplo, si su búsqueda es ineficiente - apáguelo cuando la carga llegue a un cierto nivel."Lo siento, estamos ocupados, intentemos más tarde para buscar"

3) Cargar prueba ... Use algo como ApacheBench para poner a prueba sus servidores.

4) Personalmente, creo que es mejor cambiar las conexiones "Keep-Alive". Puede reducir ligeramente el rendimiento general, pero significa que en lugar de tener algo donde el sitio funciona bien para unas pocas personas y los demás obtienen tiempos de espera, todo el mundo recibe un servicio inconsistente, si llega a ese nivel

Linux Format did un buen artículo sobre "Cómo sobrevivir a una slashdotting" ... que he encontrado útil en el pasado. Es available online as a PDF

Answer 4

Yo al menos factorizaría todo el contenido estático. Configure otro vhost en otro lugar y cargue todos los gráficos/css/js en él. Puedes comprar algunos ciclos extra descargando la porción de ese tipo de contenido. Si está realmente preocupado, puede registrarse y utilizar un servicio de distribución de contenido. Ahora hay muchos similares a Akamai y bastante baratos.

Otra idea podría ser utilizar apache mod_proxy para mantener la salida de página generada durante un período de tiempo específico. APC también sería bastante utilizable. Podría emplear la captura de buffering de salida + la última hora modificada de datos relacionados en la página, y usar la versión en caché de APC. Si la página ya no es válida, vuelva a generar y almacenar en APC nuevamente.

¡Buena suerte, será una experiencia de aprendizaje!

Answer 5

Disponga de un período beta en el que permita el uso de tantos usuarios como sea posible, mida el rendimiento de su sitio y solucione los errores antes de que se active.

Puede controlar el número de usuarios de forma explícita en una versión beta privada o beta semipública al estilo de Google, donde cada usuario tiene una serie de referencias que pueden ofrecer a sus amigos.

Answer 6

Examine el uso de Varnish - es un servidor proxy inverso de almacenamiento en caché (como calamar, pero mucho más de un solo propósito). He corrido algunos sitios bastante grandes detrás de él, parecía funcionar muy bien.

Answer 7

Primeros pasos básicos para fortalecer su sitio para un alto tráfico.

1) Use una herramienta de bajo costo como https://browsermob.com/ para probar su sitio. Como mínimo deberías mirar 100K visitantes únicos por hora. Si obtiene un anuncio fuera de la página de inicio de MSN, busque poder gestionar 500,000 ejemplares únicos por hora.

2) Mueva todo el contenido gráfico/de video estático a un CDN. Edgecast y Amazon son dos excelentes opciones.

3) Utilice Jet Profiler para perfilar su servidor MySQL para analizar cualquier consulta de bajo rendimiento. Los cambios menores pueden tener enormes beneficios.