¿Qué debo hacer para escalar un sitio web de alto tráfico?

Diseño para la concurrencia

Es decir, mientras estás codificando, planea tener varios subprocesos en funcionamiento. Planifica el estado compartido (a menudo solo la db). Plan de procesos múltiples. Plan de distribución física.

Esto le permite distribuir su sistema en múltiples máquinas y en múltiples procesos con balanceo de carga. Le permite tener procesos redundantes en ejecución en caso de fallo, y en caso de que necesite modificar el sistema en el lugar, no tiene que cancelar todo el servicio para hacerlo.

Algunas cosas que podrías considerar:

• Separar los lados de lectura y escritura de su almacenamiento de datos.
  
  • CQRS / Event Sourcing
  • CQS
  • mensaje-paso / Actores
• Evitar el proceso compartido y el estado del hilo
  • Por lo tanto, evitar el bloqueo
  • Puede evitar esto a través del sistema de tipos creando sus clases, estructuras y otros tipos de datos para que sean inmutables, es decir, no cambien después de la construcción. Especialmente para tipos de datos abstractos complejos, funciona sorprendentemente bien (por ejemplo, la implementación de jQuery)
• No está bloqueando los subprocesos del servidor web en IO. Si está utilizando ASP.Net, use páginas / acciones asíncronas con la biblioteca de patrones / tareas paralelas de APM (TPL)
• No guardar cargas de estado en el diccionario de sesión de usuario
  • Esto se debe mover a través de los subprocesos cuando se producen migraciones de subprocesos en IIS.
  • Tener enrutamiento inteligente, de manera que los recursos no seguros / estáticos no se sirven con el mismo marco de aplicación (por ejemplo, ASP.Net) que agrega sobrecarga. Mira a tener diferentes servidores web, por ejemplo.
• Escribir código de paso de continuación con un patrón de flujo de trabajo asíncrono (por ejemplo, bind (haskell) /callcc/Tasks.ContinueWith/F#'s async)
• Use la teoría de colas para calcular dónde pueden ocurrir los cuellos de botella
• Utilice actualizaciones basadas en push en lugar de pull-pull para modelos de lectura y otros estados de aplicaciones. P.ej. a través de RabbitMQ / nServiceBus
• Utilice el 'manejador de http' con las menos funciones aplicables
• Para archivos estáticos, sirva etiquetas electrónicas y políticas de caducidad de caché para permitir que la infraestructura web funcione como debería (por ejemplo, con el proxy de calamar)
• (Contráteme para resolver sus problemas de escalado y obtenga tutoriales en el sitio;))

Arquitectura de Compartir nada.

Con eso en mente, y al contrario de lo que pueda pensar, no salte a una solución de ampliación de escala de inmediato. La sobrecarga fuera del sistema frente a una llamada dentro del sistema no debe ser subestimada. Por ejemplo, se tarda mucho MUCHO en hacer una conexión de base de datos a través de cualquier interfaz de red que en hacer una llamada local. Presupueste cuánto tiempo en administración, poder y esfuerzo de ajuste es necesario en la ampliación de escala frente a los $ extra para un sistema realmente grande.

En cualquier caso, todavía hay un gran valor en las arquitecturas de "no compartir nada" y puede aplicar capas y escalar sus sistemas cuando llegue el momento.

Paralizar solicitudes en varios nombres de host

Parte del estándar HTTP es una sección que dice que los clientes web solicitarán un máximo de 2 sesiones por Host DNS. Aquí hay una solución donde usted y su alias salen de www.domain.com y obtienen una mayor concurrencia de solicitudes, lo que hace que su página se cargue más rápido:

enlace

Básicamente, implica la edición de su controlador HTTP ASP.NET para alternar los hosts de destino a los que envía los clientes, donde cada host es un CNAME a "www".

DNS seguro, rápido y confiable

Encontré algunos sitios web de alta capacidad que utilizan el servidor DNS del registrador, que no tenía SLA para el tiempo de actividad o el rendimiento. Además, sus servidores estaban ubicados en la India y la latencia por sí sola aumenta la posibilidad de que un spoofer DNS pueda envenenar a su cliente, o al caché de ISP intermedio. Esto causaría que incluso su tráfico protegido con SSL sea redirigido sin que nadie lo sepa.

La velocidad del DNS también afecta el tiempo de carga inicial de su servidor, antes de que se guarden los registros.

Uso DynDNS o Neustar para la mayoría de mis clientes, ya que tienen una infraestructura de DNS bastante sólida (aunque es cara y no tengo ninguna otra afiliación con esas compañías).

Creo que la clave será simple:

Tener código simple. Eso significa algo que miras y entiendes. A medida que expande y cambia los servidores, necesita saber qué sucede. También es posible que necesite agregar codificadores que necesiten entender rápidamente. Los enlaces y los archivos XML que llaman a un código aleatorio que no es obvio son muy malos.

Luego puedes probar y encontrar los problemas.

Mire aquí: enlace

En stellarbuild intentamos asegurarnos de que nuestros sitios web se amplíen sin interrupciones. Eso significa que debe poder saber qué hace su código y donde lo hace. Incluso si está probando una máquina diferente, no puede tardar demasiado en escalar. La mayoría de las personas solo comienzan cuando es casi demasiado tarde, tristemente. Solo puedes optimizar una vez que lo hagas en mi opinión.