Primeros días en línea: cómo no matar tu sitio

Supongamos que tiene este nuevo sitio elegante, con muchos datos (como imágenes grandes), y está a punto de ponerlo en línea. Si hace "demasiada" publicidad, durante los primeros días, el sitio se verá abrumado por las solicitudes.

¿Cómo puedo mitigar este riesgo?

He pensado en

• en vivo gradualmente, como SO y SF: beta "privada", beta pública, pública
• permitir X conexiones sesiones simultáneas, por lo que el usuario conectado todavía tiene una buena experiencia del sitio, y los demás tienen un buen mensaje de disculpa

No puedo:

• compre más servidores, ya que después de los primeros días, el sitio tendrá mucho menos tráfico :)

1. Caché tanto como puedas. Cualquier página que se cree dinámicamente debe almacenarse en caché para que los usuarios obtengan una versión estática. En los componentes de la página que consultan, la base de datos también debe almacenarse en caché.
2. Intenta usar un servicio externo como Amazon S3 para servir imágenes y multimedia (o tenlo listo para usar si el sitio de repente se ve afectado por una gran cantidad de tráfico).

Ir en vivo gradualmente puede funcionar para SOF y SF porque ya tenían publicidad y demanda incorporadas, debido a la popularidad de los blogs de Jeff y Joel. Si no tiene una base de usuarios casi garantizada como la de ellos, ponerla en marcha gradualmente podría ser fatal.

Evitaría limitar las sesiones concurrentes, ya que es difícil definir el final de una sesión causada por la inactividad. Si un usuario se va durante 15 minutos e intenta volver a cargar su página, solo para recibir un mensaje de error: acaba de perder un usuario.

¿Cuánta planificación se utilizó en su modelo de datos? ¿Ha diseñado un esquema que le permita aumentar su volumen de consultas sin costosas clases, columnas binarias o combinaciones complejas? ¿Ha ajustado el backend de su base de datos (suponiendo que tenga uno)?

¿Cómo estás sirviendo a tus 'grandes imágenes'? ¿Puedes dividir eso en un proceso de servidor web separado, incluso en un dominio separado?

¿Has probado tu sistema de carga? Herramientas como ApacheBench y Siege son invaluables.

¿Está toda su configuración en svn? ¿Está automatizado su despliegue? Se alegrará de eso cuando tenga que implementar nuestra aplicación en el segundo servidor.

Un sistema de invitación a veces puede ser una buena manera de controlar la aceptación de un sitio por parte del usuario. Distribuya un cierto número de invitaciones al principio, para que el sitio no se vea abrumado. Luego, invite a cada usuario a invitar a otros, aumentando lentamente el número de usuarios en el sitio. De esa manera, no obtendrá demasiadas personas que accedan al sitio al principio, y no obtendrá un pico masivo de tráfico.

La desventaja, por supuesto, es que puede estar rechazando a muchos usuarios al principio que no tienen invitaciones y que pueden no volver más tarde. A menos que tenga un sitio realmente bueno que la gente esté muy emocionada de usar, este podría ser un mal movimiento. Depende del sitio realmente. Además, en realidad tendría que tener un tiempo de desarrollo adicional para agregar un sistema de invitación.

Me aseguraría de que tuvieras una infraestructura de monitoreo sólida antes del lanzamiento. Necesita tener datos en los que basar sus decisiones: esto significa medir la carga de la CPU en los servidores, verificar que su carga se distribuya de manera uniforme en las cajas y que si algo se derrite, ya sabe cuál era.

Saber dónde está el problema reducirá drásticamente el tiempo que lleva responder. He visto demasiados sitios que se inician sin supervisión de ningún tipo, con la intención de que se configure más tarde ... después de que se apague el incendio. Esto está profundamente mal.

Es posible que desee buscar alojamiento de terceros de contenido estático como Amazon S3. Puede ser valioso, dependiendo de su aplicación, también nublar algunos (por mucho que odie la palabra de moda) usando Amazon EC2.

Algunos proveedores de alojamiento le permiten probar servidores privados con capacidad máxima durante un tiempo y luego conformarse con una capacidad razonable después del período de prueba.

DreamHost es un ejemplo:
http://www.dreamhost.com/hosting-vps.html