Server platt? Wie kann man so was verhindern?

[iPodFan94]

Ach ja? Dann log' Dich mal aus und rufe den Link erneut auf.

Ich will mich nicht mit Dir streiten, aber es gibt bestimmt genügend Seiten (darunter bestimmt auch das Filmarchiv im eingeloggten Zustand --> Pro Aufruf Abfrage an die DB) die nicht gecached sind. Ich weiß nicht wie es mit Lasso ist, aber mit PHP kann man Seiten recht einfach zwischenspeichern.
Das hat zwar nichts mit dem Live-Stream und dem Zustand der Seite während einer Live-Sendung zu tun, aber egal :P
Wenn man in PHP einen Benutzerlogin mit Ticketsystem programmiert, schafft dieses Script sicherlich mehr als 500 gleichzeitige Aufrufe, sogar auf meinem billigen Strato Webspace.
Was läuft denn alles auf dem Live-Sendungs Chat und Startseiten Server nebenher (also während einer Live-Sendung), oder gab es so einen enormen Ansturm an Aufrufen? Habt Ihr nicht einen Mac Pro als Server bei Euch stehen? Liegt es an der zu geringen CPU-Taktung des Servers oder an Eurem Upstream, wenn die Startseite lahmt?

[opi]

So stelle ich mir die Situation vor.

Es scheint, dass die Webseite und der Stream zwei verschiedene Dinge sind. Der Stream funktionierte für mich einwandfrei.

Um das Login zu machen und den Link auf den Stream herauszugeben braucht es nicht viel Server Leistung. Ich vermute, dass der Chat auch auf dem Login Server läuft und die Chat Logik zu viel Last erzeugt.

Eine mögliche Lösung wäre dann, das Login und den Chat auf getrennten Servern zu betreiben ev. mehrere Chat Server. Dies ist aber technisch nicht so ganz einfach zu realisieren.

Man könnte in Versuchung geraten den Chat einfach als statisches html File zu realisieren, das dann von einer Logik aktualisiert und dann auf mehrere Server verteilt wird ... etc. eine Spiele Newsseite hatte mal ein Forum auf dem Prinzip realisiert (denen gingen die Server Ports für die Web Verbindungen aus!).

Wie mans auch dreht und wendet einige Monate Programmierung wirds wohl verschlingen.

[Jörn]

Der Chat besteht aus statischen Dateien und benötigt weder eine Datenbank noch sonst eine Logik, weil beinahe jede Logik im Browser des Zuschauers läuft.

Die Last des Chats vom Mittwoch war kaum messbar, jedenfalls nicht höher als bei normalen Sendungen, was zeigt, wie extrem schlank er programmiert ist. Wenn man die Last des Servers eine halbe Stunde VOR und eine halbe Stunde NACH dem Ende der Sendung betrachtet, ergibt sich kaum ein Unterschied.

Die Last auf dem Server wurde erzeugt durch Logins und die Erzeugung/Abrechnung neuer Accounts. Der Ansturm war in einer Größenordnung, die für uns außer Reichweite liegt, egal wie wir es programmieren. Keynote-Sendungen bekommen wir mittlerweile ganz gut hin, und wir hatten vielleicht mit einer doppelten oder dreifachen Zahl an Zuschauern gerechnet (verglichen mit "normalen" Keynote-Sendungen). Aber die tatsächliche Nachfrage lag weit darüber. Nicht zehnfach höher, sondern noch mehr. Weit mehr.

[Virus]

Die Last auf dem Server

Und bei jedem Reload gab es dann neue Last d.h. jeder der ungeduldig war hat es eigentlich noch schlimmer gemacht.

[Special_B]

Also müsste man eine Möglichkeit finden, diese Sachen für Keynote Sendungen auf zusätzliche, temporär angemietete Server zu verteilen. Mit dem Stream hat das ja scheinbar funktioniert, denn der lief imho besser als bei anderen Keynote Sendungen. Da funktioniert das schon.


mfg

Special_B

[opi]

Oder man schickt jeden, der nervös clickt in eine Warteschlaufe - weil für mich hat das login funktioniert - man musste einfach nur geduldig warten.

... oder eine "bitte warten" Zwischenseite?

[Slaggi]

Aber die tatsächliche Nachfrage lag weit darüber. Nicht zehnfach höher, sondern noch mehr. Weit mehr.

Vielleicht sollte man das ganze auch mal positiv sehen, schließlich wollten so viele Leute wie noch nie Mac-TV sehen Da sieht man mal wieder wie gut Mac-TV ankommt und wie viele Menschen mittlerweile einschalten!

Es muss allerdings doch irgendeine Möglichkeit geben die Kapazitäten zu erhöhen. Wenn ihr mit tollen Sendungen so weiter macht werden die Zuschauer ja nicht weniger!

[Tim Napf]

Aber die tatsächliche Nachfrage lag weit darüber. Nicht zehnfach höher, sondern noch mehr. Weit mehr.

Uff. Das erklärt (und entschuldigt) natürlich alles.

Verflixt, mich würden wirklich mal die absoluten Zahlen interessieren.
Erwähne uns doch vielleicht in Deinem Testament, der Notar soll uns dann in 70 Jahren, wenn Dir dann alles egal ist, mal die Zahlen dieser Keynote hier ins Forum schreiben.

[mwuebben]

Aus meiner beruflichen Praxis kenne ich dieses Verhalten auch (Ticketsysteme).

Das Problem liegt aber nicht an der Größe einer Webseite oder der verwendeten Scripting-Sprache (Lasso oder PHP oder so) und auch nicht an einer Datenbankanbindung, sondern primär daran, dass der Webserver bei jedem Aufruf einen definierten Speicherbereich für die Anfrage reserviert. Dadurch wird bei vielen Anfragen in kürzester Zeit der gesamte Hauptspeicher des Systems reserviert und was darüber hinausgeht geswapt (schreibt man das so?. Egal, also auf Festplatte ausgelagert). Und jetzt geht alles um ein Faktor 1000 langsamer (RAM-Zugriff in Nano-Sekunden, HD-Zugriff im Millisekunden).

Wie machen es andere?
Tja, da wird es schon richtig teuer. Man müsste einen Webserver-Cluster aufbauen. D.h., es müssten viele Webserver zu einem Gesamtsystem zusammengeschaltet werden. Das ist aber komplizierter als es auf den ersten Blick klingt.

So wie ich das sehe, muss ja auch abgerechnet werden und dann muss man schon auf eine Datenbank zugreifen. Bei einem Cluster ist dies schwieriger zu programmieren, als es bei einem einzelnen Server der Fall ist. Da die Systeme im Cluster auch noch auf verschiedenen Rechnern laufen, sind die Verbindungen zwischen den Webservern und dem Datenbankserver über Netzwerkverbindungen zu lösen. Dadurch entsteht wieder ein Flaschenhals.

Am Beispiel Google kann man sehr gut sehen, wie die das als Cluster machen.
Wenn man wissen will, welche IP-Adresse der Webserver www.google.de hat, geht man einfach ins Terminal und tippt folgenden Befehl ein:

shell> nslookup www.google.de

> Non-authoritative answer:
> www.google.de canonical name = www.google.com.
> www.google.com canonical name = www.l.google.com.
> Name: www.l.google.com
> Address: 74.125.39.106
> Name: www.l.google.com
> Address: 74.125.39.99
> Name: www.l.google.com
> Address: 74.125.39.105
> Name: www.l.google.com
> Address: 74.125.39.103
> Name: www.l.google.com
> Address: 74.125.39.147
> Name: www.l.google.com
> Address: 74.125.39.104

Und hier liegt die Magic. Man bekommt nicht eine IP-Adresse, sondern einen ganzen Satz von Adressen. Mache ich nun von meinem Rechner eine Anfrage zu Google, dann bekomme ich diese Liste. Da diese nicht immer in der gleichen Reihenfolge vom Nameserver geliefert wird, fragt mein System jedes mal einen anderen Webserver an. It's that simple, wie Steve immer sagt

Nun, wie man es dreht und wendet. Mit einem Webserver (bei Mac-TV bekomme ich nur eine IP zurückgeliefert) wird man diesen Ansturm nicht mal mit der kleinsten Webseite lösen können.

Da ich nicht weiß, wie die Abrechnung realisiert ist, hätte ich mal einen ganz anderen Vorschlag, der aber auch ziemlich schwachsinnig sein kann, eben wegen Abrechnung:

Könnte man nicht eine Einladungsmail verschicken, in der ein Link mit alle wichtigen Daten zur Authentifizierung enthalten ist?
Dadurch bräuchte man den Umweg über den Webserver nicht mehr.

Okay, wie gesagt, ich weiß nicht, wie das mit der Abrechnung der Accounts funktioniert. Daher kann mein Vorschlag auch unsinnig sein. Nur mal so als Frage.

[Special_B]

Hehe, man könnte den Login/die Punkteabbuchung schon mehrere Stunden vorher laufen lassen und dann ne Adresse bekommen mit der man dieses Ticket System umgeht. Dann wäre die Last auf den ganzen Tag verteilt und man kommt leichter zur Sendung.


mfg

Special_B

[Jörn]

Special_B, so ein System war bei uns früher im Einsatz, aber in den letzten Jahren war es nicht mehr nötig, da die Hardware inzwischen lesitungsfähig genug geworden war.

[Special_B]

Cool, dann bleiben ja nur 2 Möglichkeiten: Entweder noch ein paar Xserves, oder für die Keynote Sendungen dieses alte System wieder. Ich hätte kein Problem damit, bei solchen Anlässen das Ticket im Laufe des Tages zu lösen und dann Abends wieder einzuschalten. Das könnte ja unterwegs auch mit dem iPhone erledigt werden.


MfG

Special_B

[Gerhard Uhlhorn]

Ist denn mein Eingangsvorschlag mit einer Warteseite, wo dann die Besucher so abgeholt werden wie es der Server eben schafft, so blöd gewesen dass es gar nicht mehr diskutiert wird?

[mwuebben]

Hallo Gerhard,

wie ich zuvar schrieb, liegt es gerade an der Sache, dass es über eine Webseite läuft.
Jörn müsste sein gesamtes System auf einen Cluster umstellen, was ziemlich aufwendig wäre. Dies kann nicht die Lösung sein.
Es muss ein Weg gefunden werden, den Flaschenhals Webserver zu umgehen.

[Jörn]

Gerhard, wir hatten früher ein solches System, womit die User häppchenweise zur Sendung geleitet wurden, um einen plötzlichen Ansturm abzufangen und um dauernde Reloads zu verhindern. Als die Server-Hardware leistungsfähiger wurde, war das nicht mehr nötig. Vielleicht sollten wir es wieder in einer modernisierten Form einführen.