Sitio pesado de ancho de banda ... ¿usa la ubicación conjunta?


11

Estoy trabajando en un sitio web que probablemente tenga mucho ancho de banda. Una característica importante del sitio cuando está en uso activo puede obtener hasta 1 Mbps para una sola sesión. Afortunadamente, una vez que los usuarios superen el nuevo factor de juguete, el uso de esta función probablemente será del 1-5% o menos (probablemente mucho menos) del tiempo de sesión.

Sin embargo, es probable que los nuevos usuarios jueguen un poco con esta función, especialmente en el lanzamiento. Estoy muy preocupado por el uso del ancho de banda.

Este es más o menos un nicho de mercado, por lo que nunca necesitaré escalar a niveles locos como YouTube. Sin embargo, es completamente posible que sea un par de terabytes / mes.

¿La ubicación conjunta es mi mejor opción? ¿Qué servicios de ancho de banda baratos (colocación / hospedado / nube / lo que sea) existen?


Cuánto ancho de banda estamos hablando en realidad (picos), que determina su nivel de compromiso, lo que influye fuertemente en si un colo es una idea buena o no (teniendo en cuenta el 95% de facturación baldosas de ser bastante común)
Tim Mensaje

1
De acuerdo, creo que me estoy inclinando hacia el establecimiento de un límite estricto de 10 Mbps. Puedo tener una fase beta limitada. Comenzaría con esto completamente abierto, y cambiaría a cuentas de vista previa limitadas si me inundan. Eso debería funcionar.
darron

¡Muy curioso qué tipo de contenido dinámico está generando que requiere 1Mbps para descargar! ¿Video en vivo? De todos modos, es posible que desee consultar esta pregunta relacionada: serverfault.com/questions/148629
Greg Bray

Respuestas:


6

Mucho dependerá de cuántas sesiones concurrentes esté esperando. Si es probable que haya más de unas pocas sesiones concurrentes, necesitará algo que le otorgue una conexión de 100Mbit, 1Gbit si espera más de 50.

También dependerá de qué tipo de resiliencia requiera: si debe tener garantías de tiempo de actividad y otros SLA y / o sistemas de recuperación de fallas para asumir el control en caso de un problema (porque el proyecto es lo suficientemente importante para un corto período de tiempo de inactividad) ser vergonzoso), entonces sus opciones son más limitadas y sus costos serán más altos.

Si puede separar los datos grandes del resto de la aplicación, entonces no necesita mover todo a una nueva solución de alojamiento. Por ejemplo, si los elementos de gran ancho de banda son archivos de video, entonces podría alquilar un servidor dedicado con buen ancho de banda en algún lugar y alojarlos en eso: puede obtener servidores en buenos hosts con ancho de banda decente y conexiones de 100mbit + sorprendentemente a bajo precio en estos días (pago $ 50 / mes para un servidor pequeño con un enlace de 10Mbit que podría saturar en ambas direcciones 24/7 si fuera necesario, por lo que un enlace de 100Mbit con un servidor más robusto conectado no será costoso a menos que necesite tiempo de actividad garantizado y otros SLA y / o servidores gestión del proveedor de hosting). Si el servidor solo sirve archivos estáticos (incluso grandes), no necesita una gran máquina en términos de CPU y RAM, solo unidades rápidas y ancho de banda. También podría valer la pena buscar soluciones alojadas "en la nube" o una red de entrega de contenido; podrían ser más fáciles de escalar si no adivina cuánto ancho de banda necesita es, en teoría, mucho más resistente (por lo que podría obtener una garantía de tiempo de actividad decente) con compensación si no cumplen con ese SLA). Mantener la acción de acaparamiento de ancho de banda separada de esta manera tiene la ventaja adicional de que si la característica de ancho de banda alto atrae suficiente atención para hacer que se arrastre, no bloqueará todas sus otras características al mismo tiempo.


Sin SLA, sin requisitos de tiempo de actividad locos. Actualmente utiliza una buena cantidad de CPU / RAM por sesión. Sin embargo, una sola caja robusta debería manejar una buena cantidad de sesiones concurrentes.
darron

1

Puramente histórica:
en los días previos a los juegos de Facebook, todas las personas usaban MMO de formato de texto basados ​​en navegador.

Una relativamente nueva fue Ogame. Era un gráfico pesado y un sistema de mapas de 9 veces 999 páginas (9 universos con 999 sectores con espacio para 15 planetas cada uno, y cada planeta podría tener una luna).

La cantidad de usuarios que se unieron fue una locura y la cantidad de tráfico aún más.

Entonces, ¿qué hicieron para resolverlo? Comenzaron a usar un sistema de plantillas PHP y permitieron a los usuarios alojar las imágenes y los archivos CSS ellos mismos. Todo lo que tenía que hacer era hacer clic en una casilla de verificación e ingresar la ruta absoluta a la carpeta base. Guardarían esto en su base de datos, usarían el <base>elemento HTML y el sistema de plantillas establecería el URI de http: // ruta / a / imagen a archivo: /// ruta / a / imagen

Después de eso, todos los enlaces img podrían permanecer iguales. No era necesario descargar nada porque los usuarios ya lo tenían. Esto significa una carga de página más rápida para el usuario (lo que significa mejores revisiones de productos) y también un menor uso de ancho de banda para la empresa que aloja el sitio.

Y como una ventaja adicional, lo vendieron como "crea tus propios fondos e imágenes personalizados, ¿no somos buenos tipos por dejarte hacer esto?"


1

Tenemos un sitio de alto tráfico y tenemos muchas imágenes cargadas en cada página. Tenemos servidores dedicados pero decidimos poner las fotos en Amazon S3 . Parece que puede estar hablando de archivos de video o algún otro tipo de archivo grande que creo que todavía se aplicaría aquí. Aquí hay algunos pros y contras (para nosotros)

Pros

  • Se necesita menos espacio en disco en nuestros servidores
  • Menos ancho de banda para nuestros servidores
  • Nuestros archivos de registro son significativamente más pequeños
  • Podemos integrarlo fácilmente con Amazon CloudFront para que la carga sea aún más rápida para los visitantes

Contras

  • Cuesta un poco más. Podríamos ahorrar un poco de dinero al tenerlo en nuestros propios servidores
  • Menos control sobre ellos (Amazon) bajando ... por suerte para nosotros, realmente no bajan. :)

otros pensamientos

Si no estás hablando de archivos multimedia o descargas de archivos grandes, mi respuesta y varias de las otras podrían no tener sentido. Danos más detalles y haremos todo lo posible para ayudarte.


0

Un colo realmente puede tener más sentido, si puede justificar el compromiso mínimo (generalmente 5mb) con la facturación del percentil 95. Esto significa que nunca pagará el 5% superior de los picos, lo que termina siendo más barato que un CDN de terceros. Es difícil de decir, realmente necesitamos ver exactamente cuánto está usando.
Tim Post

Mi uso será contenido casi completamente dinámico, con una gran huella de CPU / memoria por sesión. Después de jugar con la herramienta de estimación de precios de AWS, parece ser mucho más barato optar por la colocación.
darron

Ah, supuse que las piezas pesadas de ancho de banda serían medios que podrías poner en un CDN, parece que presumí mal. Sin embargo, si tiene fragmentos dinámicos que se procesan de manera predecible (un conjunto finito de posibles "fragmentos" de datos) aún podría poner todo eso en un CDN. Dejaré de intentar adivinar tu aplicación ahora. :-)
artlung

0

Dependiendo del estado / país de destino (o del mundo), usaría muchas soluciones de clúster ("Nube") en diferentes ubicaciones (las redes de ubicación deben ser emparejadas ;-)). Por un lado, usted tiene el control total sobre su CDN, pero en el otro sitio tiene mucho que hacer (como monitorear, cuidar la infraestructura de software y hardware y mucho más).

Entonces soluciones "administradas" como AWS o algo así. Hay muchos proveedores de CDN / Cloud que ofrecen una gran variedad de características.

OFFTOPIC: Eche un vistazo a Puppet [1] :-)

[1] http://www.puppetlabs.com/


Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.