Bandbreitenintensive Site… Co-Location verwenden?


11

Ich arbeite an einer Website, die wahrscheinlich sehr bandbreitenintensiv ist. Eine wichtige Funktion der Site bei aktiver Nutzung kann für eine einzelne Sitzung bis zu 1 Mbit / s erreichen. Glücklicherweise wird die Verwendung dieser Funktion, sobald Benutzer den neuen Spielzeugfaktor überwunden haben, wahrscheinlich 1-5% oder weniger (wahrscheinlich viel weniger) der Sitzungszeit betragen.

Neue Benutzer werden jedoch wahrscheinlich ein gutes Stück mit dieser Funktion spielen, insbesondere beim Start. Ich bin sehr besorgt über die Bandbreitennutzung.

Dies ist mehr oder weniger ein Nischenmarkt, daher muss ich nie auf verrückte Level wie YouTube skalieren. Es ist jedoch durchaus möglich, dass es ein paar Terabyte / Monat sind.

Ist Co-Location meine beste Option? Welche günstigen Bandbreitendienste (Colocation / Hosted / Cloud / was auch immer) gibt es?


Wie viel Bandbreite sprechen wir tatsächlich (Spitzen), die Ihr Engagement bestimmt, was stark beeinflusst, ob ein Colo eine gute Idee ist oder nicht (da 95% der Kacheln häufig verwendet werden)
Tim Post

1
Okay, ich glaube, ich neige dazu, ein hartes Limit bei 10 Mbit / s festzulegen. Ich kann eine begrenzte Beta-Phase haben. Ich würde damit weit offen beginnen und zu eingeschränkten Vorschau-Konten wechseln, wenn ich überfüllt bin. Das sollte funktionieren.
Darron

Sehr neugierig, welche Art von dynamischem Inhalt Sie generieren, für dessen Download 1 Mbit / s erforderlich ist! Live-Video? Wie auch immer, vielleicht möchten Sie diese verwandte Frage überprüfen: serverfault.com/questions/148629
Greg Bray

Antworten:


6

Viel hängt davon ab, wie viele gleichzeitige Sitzungen Sie erwarten. Wenn mehr als ein paar gleichzeitige Sitzungen wahrscheinlich sind, benötigen Sie etwas, das Ihnen eine 100-Mbit-Verbindung gewährt, 1 Gbit, wenn Sie mehr als 50 erwarten.

Dies hängt auch davon ab, welche Art von Ausfallsicherheit Sie benötigen - ob Sie über Verfügbarkeitsgarantien und andere SLAs und / oder Failover-Systeme verfügen müssen, um diese im Falle eines Problems zu übernehmen (da das Projekt für eine kurze Ausfallzeit wichtig genug ist peinlich sein), dann sind Ihre Möglichkeiten eingeschränkter und Ihre Kosten werden höher sein.

Wenn Sie die großen Datenmengen vom Rest der App trennen können, müssen Sie nicht alles auf eine neue Hosting-Lösung verschieben. Wenn es sich bei den Elementen mit großer Bandbreite beispielsweise um Videodateien handelt, können Sie irgendwo einen dedizierten Server mit guter Bandbreite mieten und darauf hosten. Sie können Server auf guten Hosts mit angemessener Bandbreite und Verbindungen mit mehr als 100 MBit heutzutage überraschend günstig erhalten (ich bezahle 50 US-Dollar pro Monat) Für einen kleinen Server mit einer 10-Mbit-Verbindung, die ich bei Bedarf rund um die Uhr in beide Richtungen sättigen könnte, ist eine 100-Mbit-Verbindung mit einem leistungsstärkeren Server nicht teuer, es sei denn, Sie benötigen eine garantierte Verfügbarkeit und andere SLAs und / oder Server Management vom Hosting-Anbieter). Wenn der Server nur statische Dateien (auch große) bereitstellt, benötigen Sie in Bezug auf CPU und RAM nicht viel von einem Computer, sondern nur schnelle Laufwerke und Bandbreite. Es könnte sich auch lohnen, sich mit "Cloud" gehostete Lösungen oder ein Netzwerk für die Bereitstellung von Inhalten anzusehen. Diese sind möglicherweise einfacher zu skalieren, wenn Sie nicht genau wissen, wie viel Bandbreite Sie theoretisch benötigen, und sind ausfallsicherer (sodass Sie möglicherweise eine angemessene Verfügbarkeitsgarantie erhalten) mit Entschädigung, wenn sie diese SLA nicht einhalten). Wenn Sie die Bandbreiten-Hogging-Aktion auf diese Weise getrennt halten, hat dies den zusätzlichen Vorteil, dass die Funktion mit hoher Bandbreite, wenn sie genügend Aufmerksamkeit auf sich zieht, um sie zu crawlen, nicht alle anderen Funktionen gleichzeitig blockiert.


Keine SLAs, keine verrückten Verfügbarkeitsanforderungen. Derzeit wird pro Sitzung ein ordentlicher Teil der CPU / des Arbeitsspeichers verwendet. Eine einzelne bullige Box sollte jedoch eine gute Anzahl von gleichzeitigen Sitzungen verarbeiten.
Darron

1

Rein historisch:
In den Tagen vor den Facebook-Spielen waren alle Leute mit browserbasierten MMOs im Textformat beschäftigt.

Ein relativ neuer war Ogame. Es war grafisch schwer und ein Kartensystem von 9 mal 999 Seiten (9 Universen mit 999 Sektoren mit Platz für jeweils 15 Planeten, und jeder Planet könnte einen Mond haben).

Die Anzahl der Benutzer war verrückt und das Verkehrsaufkommen umso mehr.

Was haben sie getan, um das Problem zu lösen? Sie begannen mit der Verwendung eines PHP-Vorlagensystems und ermöglichten es den Benutzern, die Bilder und CSS-Dateien selbst zu hosten. Sie mussten lediglich ein Kontrollkästchen aktivieren und den absoluten Pfad zum Basisordner eingeben. Sie würden dies in ihrer Datenbank speichern, das HTML- <base>Element verwenden und das Vorlagensystem den URI von http: // Pfad / zu / Bild zu Datei: /// Pfad / zu / Bild setzen

Danach könnten alle img-Links gleich bleiben. Es musste nichts heruntergeladen werden, da die Benutzer es bereits hatten. Dies bedeutet eine schnellere Seitenladung für den Benutzer (was bessere Produktbewertungen bedeutet) und eine geringere Bandbreitennutzung für das Unternehmen, das die Website hostet.

Und als zusätzlichen Bonus verkauften sie es als "Erstelle eigene Hintergründe und Bilder, sind wir nicht nette Leute, die dich das machen lassen?"


1

Wir haben eine stark frequentierte Website und viele Bilder, die auf jeder Seite geladen werden. Wir haben dedizierte Server, haben uns aber entschieden, die Bilder auf Amazon S3 zu stellen . Es hört sich so an, als würden Sie über Videodateien oder eine andere Art von großen Dateien sprechen, von denen ich denke, dass sie hier immer noch zutreffen würden. Hier sind einige Vor- und Nachteile (für uns)

Vorteile

  • Auf unseren Servern wird weniger Speicherplatz benötigt
  • Weniger Bandbreite für unsere Server
  • Unsere Protokolldateien sind erheblich kleiner
  • Wir können es einfach in Amazon CloudFront integrieren , um das Laden für Besucher noch schneller zu machen

Nachteile

  • Es kostet ein bisschen mehr. Wir könnten ein wenig Geld sparen, indem wir es auf unseren eigenen Servern haben
  • Weniger Kontrolle über sie (Amazon) sinkt ... zum Glück fallen sie nicht wirklich. :) :)

andere Gedanken

Wenn Sie nicht über Mediendateien oder Downloads großer Dateien sprechen, sind meine Antwort und einige der anderen möglicherweise nicht sinnvoll. Geben Sie uns weitere Details und wir werden unser Bestes geben, um Ihnen zu helfen.


0

Ein Colo kann tatsächlich sinnvoller sein, wenn er das Mindest-Commit (normalerweise 5 MB) mit einer Abrechnung mit dem 95. Perzentil rechtfertigen kann. Dies bedeutet, dass er niemals für die Top 5% der Peaks bezahlen wird, was letztendlich billiger ist als ein CDN eines Drittanbieters. Es ist schwer zu sagen, wir müssen wirklich genau sehen, wie viel er verwendet.
Tim Post

Ich verwende fast ausschließlich dynamische Inhalte mit einem hohen CPU- / Speicherbedarf pro Sitzung. Nach dem Spielen mit dem AWS-Preisschätzungstool scheint es viel billiger zu sein, Colocation zu verwenden.
Darron

Ah, ich nahm an, dass die bandbreitenintensiven Teile Medien sind, die Sie auf ein CDN legen könnten. Klingt so, als hätte ich falsch angenommen. Wenn Sie jedoch dynamische Blöcke haben, die auf vorhersehbare Weise verarbeitet werden (eine endliche Menge möglicher Daten- "Blöcke"), können Sie all dies dennoch in ein CDN einfügen. Ich werde jetzt aufhören, über Ihre App zu raten. :-)
Artlung

0

Abhängig vom Zielstaat / Land (oder der Welt) würde ich viele Clusterlösungen ("Cloud") an verschiedenen Standorten verwenden (Standortnetzwerke sollten überprüft werden ;-)). Auf der einen Seite haben Sie die volle Kontrolle über Ihr CDN, auf der anderen Seite haben Sie viel zu tun (wie Überwachung, Pflege der Soft- und Hardware-Infrastruktur und vieles mehr).

Also "verwaltete" Lösungen wie AWS oder so. Es gibt viele CDN / Cloud-Anbieter, die eine Vielzahl von Funktionen anbieten.

OFFTOPIC: Schau dir Puppet an [1] :-)

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


Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.