Server platt? Wie kann man so was verhindern?

[McVitji]

Sei es wie es sei - ich ohne technisches Verständnis für all das. Ich war auch frustriert erst so nach fast 'ner dreiviertel Stunde in die Sendung zu kommen. Und ich habe mir wirklich die Hände fast blau geprügelt um nicht auf Reload zu drücken. Aber wenn man gesehen hat, welche Seiten vor die Wand gefahren sind, die finanziell ein viel größeres Rad drehen ...

Nicht dass ich nicht die Ticker selbst verfolgen konnte, aber die Präsentation durch Euch Moderatoren ist doch ganz was anderes. Zudem im Wissen der Vorfreude von Jörn bei der Vorstellung neuer Produkte - ich hätte so gern das Sabbern (sorry nicht bös' gemeint) bei jeder neuen Info von Gerd gesehen ;)

Wo ich dann schwer begeistert war, war dann die Entschuldigungs-E-Mail mit Gratis-Ticket (egal wg. Abo) und Sonder-LogIn.

Ich glaube Leute, am meisten hat es die Mac-TVler gestört, dass sich nicht alle x-Millionen Leute einloggen konnten - die machen das (weitestgehend) aus Spaß und das wie im Olympiastadion möglichst vor einem Haufen Zuschauern.

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

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

[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?

[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

[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]

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

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

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

[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!

[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?

[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

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

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

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