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

¿Qué mejores prácticas deberían llevarse a cabo para un sitio web que necesita "escalar" para manejar la capacidad? Esto es especialmente relevante ahora que las personas están considerando la nube, pero pueden estar perdiendo los fundamentos.

Estoy interesado en escuchar cualquier cosa que considere una mejor práctica, desde tareas de nivel de desarrollo, hasta infraestructura y gestión.

Diseño para concurrencia

Es decir, mientras está codificando, planee tener varios hilos en funcionamiento. Planifique el estado compartido (a menudo solo el db). Plan para múltiples procesos. Plan de distribución física.

Esto le permite distribuir su sistema en múltiples máquinas y en múltiples procesos con equilibrio de carga. Le permite tener procesos redundantes ejecutándose en caso de falla, y en caso de que necesite modificar el sistema en el lugar, no tiene que eliminar todos los servicios para hacerlo.

Algunas cosas que podrías considerar:

• Separar los lados de lectura y escritura de su almacenamiento de datos.
  
  • CQRS / Abastecimiento de eventos
  • CQS
  • Pasar mensajes / Actores
• Evitar el proceso compartido y el estado del hilo
  • Por lo tanto, evitando 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, que 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 bloquea los hilos del servidor web en IO. Si está utilizando ASP.Net, use páginas / acciones asíncronas con el patrón APM / biblioteca paralela de tareas (TPL)
• No guardar cargas de estado en el diccionario de sesión de usuario
  • Esto debe moverse a través de los subprocesos cuando se producen migraciones de subprocesos en IIS.
  • Tener enrutamiento inteligente, de modo que los recursos no seguros / estáticos no se atiendan con el mismo marco de aplicación (por ejemplo, ASP.Net) que agrega sobrecarga. Mira 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
• Use actualizaciones push-en lugar de pull-based para leer modelos y otro estado de la aplicación. Por ejemplo, a través de RabbitMQ / nServiceBus
• Utilice el 'controlador de http' aplicable con menos funciones
• 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 proxy calamar)
• (Contratame para resolver tus problemas de escala y obtener tutoriales en el sitio;))

Compartir nada de la arquitectura.

Con eso en mente, y contrario a lo que pueda pensar, no salte a una solución de escala inmediata. La sobrecarga fuera del sistema frente a una llamada dentro del sistema no debe sopesarse. Por ejemplo, toma MUCHO más tiempo hacer una conexión DB a través de cualquier interfaz de red que hacer una llamada local. Haga un presupuesto de cuánto tiempo se necesita en administración, potencia y esfuerzo de ajuste para escalar en escala frente a los $ adicionales para un verdadero sistema grande.

De todos modos, 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.

Paralelizar solicitudes sobre 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 en la que usted y su alias www.domain.com obtienen una mayor concurrencia de solicitudes, lo que hace que su página se cargue más rápido:

/programming/3653609/how-do-i-code-my-asp-net-page-to-parallelize-downloads-across-hostnames

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

DNS seguro, rápido y confiable

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

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

Utilizo DynDNS o Neustar para la mayoría de mis clientes, ya que tienen una infraestructura DNS bastante sólida (aunque es costosa y no tengo otra afiliación a esas empresas).

Creo que la clave será simple:

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

Entonces puedes probar y encontrar los problemas.

Mire aquí: http://blog.servint.net/2013/08/27/going-big-how-to-scale-a-website-part-1-infrastructure-that-scales/

En stellarbuild intentamos asegurarnos de que nuestros sitios web escalen sin tiempo de inactividad. Eso significa que necesita poder saber qué hace su código y dónde 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, por desgracia. Puede optimizar solo una vez que lo haga en mi opinión.