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

14

¿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.

goodguys_activate
fuente
1
Mire: highscalability.com
Casebash
¿Alguien que sepa sobre Windows Server App Fabric y el almacenamiento en caché puede publicar algo aquí? No soy un experto en esta área y quiero aprender más.
goodguys_activate
¿Qué quieres saber sobre AppFabric?
Henrik
Hay algunos consejos sobre cómo escalar un sitio web, échale un vistazo Incluyendo: nivel de secuencia de comandos del servidor de nivel front-end Modelo y nivel de diseño de base de datos Escala horizontal del servidor, Sharding Ver más: olivetit.blogspot.com/2013/05/…

Respuestas:

16

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.

Fishtoaster
fuente
13

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;))
Henrik
fuente
4

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.

Jé Queue
fuente
0

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".

goodguys_activate
fuente
1
Esta respuesta tiene más que ver con el rendimiento del lado del cliente y nada que ver con el escalado horizontal del lado del servidor.
Ken Liu
Estaba pensando más en la línea de un nivel medio que agrega otras fuentes de datos a través de HTTP. Azure Table, OData son solo algunos ejemplos ... Aún así, es el servidor el que le dice al navegador (javascript) qué hacer.
goodguys_activate
0

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).

goodguys_activate
fuente
2
Err ... ¿DNS es realmente un cuello de botella serio para ti? Creo que sería una de las últimas cosas para optimizar.
Fishtoaster
@Fishtoaster: parte editada en negrita. Originalmente soy un administrador de sistemas, y la seguridad de DNS juega un papel importante en la validación SSL. Surgen problemas de conectividad y rendimiento de DNS, tales como: problemas de enrutamiento BGP hacia SOA, problemas con Anycasting (para CDN), problemas de latencia, envenenamiento de caché y más. Escribí una herramienta de escaneo de mejores prácticas de DNS (nivel de cable) que pondré en Internet pronto. Siéntase libre de probarlo ya que cubre muchos de los problemas de conectividad que mencioné. (o envíeme un correo electrónico y le explicaré más)
goodguys_activate
2
No estoy diciendo que no haya problemas de rendimiento relacionados con DNS como los que enumera. Simplemente me parece que surgirían preocupaciones mucho más básicas (acceso a la base de datos, almacenamiento en caché de páginas, complejidad de bucle de código simple, equilibrio de carga del proceso del servidor, selección del punto de distribución de hardware, etc.) y se resolverían en varios órdenes de magnitud mientras se escala antes del DNS relacionados con el tema serían un problema.
Fishtoaster
... Estoy totalmente de acuerdo en que hay cosas más importantes de las que preocuparse, tal como usted menciona. Quizás es por eso que esta idea tiene una calificación de cero :) ... pero, de nuevo, soy el único que respondió esta pregunta hasta ahora.
goodguys_activate
1
El rendimiento de DNS ciertamente puede ser un cuello de botella masivo: puede que no haya una diferencia de ms entre bueno y malo, pero debido a que el DNS se ve afectado en cada llamada (o casi todas las llamadas) puede sumar realmente rápido. Especialmente cuando entras en acrobacias modernas de CDN.
Wyatt Barnett
0

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.

msj121
fuente