it-swarm-es.com

¿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 a nivel de desarrollo, hasta infraestructura y gestión.

14
goodguys_activate

Diseño para concurrencia

Es decir, mientras está codificando, planee tener varios subprocesos 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.

16
Fishtoaster

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 se debe mover 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 sus cuellos de botella
  • Utilice actualizaciones basadas en Push en lugar de pull para leer modelos y otros estados de la aplicación. P.ej. 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;))
13
Henrik

arquitectura Share Nothing.

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 en escalamiento horizontal versus 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.

4
Jé Queue

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 por tiempo de actividad o rendimiento. Además, sus servidores estaban ubicados en India y la latencia por sí sola aumenta la posibilidad de que un El spoofer DNS podría envenenar el caché de su cliente o ISP intermedio, lo que 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 ninguna otra afiliación a esas empresas).

0
goodguys_activate

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

https://stackoverflow.com/questions/3653609/how-do-i-code-my-asp-net-page-to-parallelize-downloads-across-hostnames

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

0
goodguys_activate

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 comprender 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- escalas/

En stellarbuild intentamos asegurarnos de que nuestros sitios web escalen sin tiempo de inactividad. Eso significa que debe 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. Puedes optimizar solo una vez que lo hagas en mi opinión.

0
msj121