Wie viele Spieler (online) schafft ihr pro Server?

Hallo zusammen,

nachdem bei unserem Browsergame die erste geschlossene Beta-Runde so langsam gegen Ende geht und wir nun featurekomplett sind (für das erste öffentliche Release), stehen nun noch Optimierungen bzgl. Performance u.a. an.

Ein Last-Generator erzeugt uns eine Last, die den Statistiken aus der Beta-Runde entspricht, so dass wir die Performance in Abhängigkeit der Anzahl der Spieler, die gerade online sind, messen können. So können wir die maximal Zahl an Spielern, die (vernünftig) gleichzeit online sein können, herausfinden.

Natürlich ist es unser Ziel, diese Zahl möglichst zu maximieren - andererseits möchten wir uns auch realistische Ziele setzen.

Daher meine Frage an andere Betreiber: Wie viele User können bei euch gleichzeitig online sein? (Wohlwissend, dass diese Zahl natürlich nicht heißt, dass ich sie bei einem evtl. ganz anderen Spiel ebenso erreichen könnte, aber ein Richtwert wäre mir schon eine Hilfe.)

Und: Wie sieht eure Serverstruktur aus, um das zu schaffen? (Ein Server pro Spiel-Welt oder getrennte Web-/App-DB-Server, Replikation? Nutzt ihr High-End-Server oder lieber viele kleinere?)

Danke für alle Hinweise, Tipps und Aussagen!

Philipp

Hi,

hab selbst vor einer Weile einen Thread zum Thema (unter Umsetzung) eröffnet, da findest du ein paar Infos:

BEITRAG

hmm, danke, aber kann es sein dass dieser Thread im geschlossenen Entwicklerbereich liegt (zu dem ich keinen Zugang habe)?

...und ich ihn vielleicht auch deshalb nicht gefunden habe...

Jupp.

Zur Beantwortung der Frage wäre es auch nicht unwesentlich auf welche Technik du setzt.

Die Pixeltamers haben z.B. einen eigenen Webserver als Backend für ihr BG in C++ geschrieben, der 3 Fantastillionen User gleichzeitig bedienen kann. Natürlich sind das Vollprofis, aber mit einer Standard-PHP-Lösung kommst du niemals in diese Klasse.

wie gesagt - es geht mir primär um ein paar Richt-/Vergleichswerte, je nach Bedienkonzept variiert ja sicher auch die Anzahl Requests/Zeit/User sowie der Aufwand/Request. Daher hab ich über unsere Technik geschwiegen, aber wenn es hilft: Wir nutzen C#/.net, also IIS+Asp.net und eine Standalone-C#-Anwendung als Backend (die auf eine Postgre-Datenbank zugreift).

Mir würde eigentlich 1 Fantastillion gleichzeitiger User schon reichen :-)

bzgl. ein großer oder viele kleine server: Ich musste sowas noch nie machen, aber wenn meine Last so steigt dass ein Server nicht mehr reicht werde ich mir einen zweiten dazustellen und nicht meinen bisherigen aufrüsten. Dann würde ich erstmal so splitten, dass ich einen DB Server, einen Static-Server und einen dynamischen Server habe. Ja nachdem wie sich dann die Last verändert würde ich diese Server passend aufrüsten.

Wie ist denn deine bisherige Auslastung bei wievielen aktiven gewesen?

Original von Fornax

[...] einen Static-Server [...]

Wir nutzen für Wurzelimperium atm das CDN von amazon, das ist kostengünstiger wie tonnenweise eigene Server (vor allem mit Blick auf die Anbindung [reinen Fileservern reichen die 100Mbit/s oft nicht]) Allerdings weis ich nicht ab wann sich so etwas lohnt (wir haben Traffic deutlich im TByte bereich... [pro Monat])

Die Datenbank auszulagern ist natürlich auch intelligent ;-)

Also dem wage ich zu widersprechen. Ich hab mir gerade noch einmal die S3 Preise kurz überflogen:

1 TB traffic out kostet zwischen 170$ bis 100$ (0.17 - 0.1 $/gb in europe). + 0.012$ pro 10k Get Requests...

Hetzner dürfte zZ der Standardhoster mit dem besten trafficpreis sein mit irrwitzen 15/TB.  Bei anderen Anbietern ists in der Regel noch ein ganzes stück teurer, allerdings sind die ersten 1-5 TB normalerweise stark durch den gemieteten Server subventioniert und für die meißten wird der inklusiv Traffic der Server schon ausreichen.

Es gibt andere gute Gründe ( z.b. kein eigenen Server administrieren zu müssen, Ausfallsicherheit, bessere Verfügbarkeit, bessere Zugrifzeiten) auf ein CDN wie S3 zu setzen, aber die Traffic-Kosten sind es sicher nicht.

Bis eine 100mbit Leitung mit den Bildern eines Bg ausgelastet ist, dauerts ne weile und wer es schafft,  der ist eigtl definitiv kostengünstiger mit eigenen Servern beraten als ein CDN.

Im allgemeinen sagt man Frontend Scale-out , Backend scale-up d.h. übertragen auf ein gängiges Browserspiel: die webserver viele kleine gleiche kisten und die DB erstmal mit immer fetteren Kisten pimpen. Ideal wäre natürlich eine Code/DB Struktur indem auch das backend mit vielen servern betrieben werden kann, ist aber erstmal meist nicht über nacht in die schon existierende CodeStruktur einfügbar.

Naja, ich hatte das vielleicht ein wenig blöd formuliert, allerdings gehe ich schon von einer Kostenersparnis aus (ich weiß es aber nicht).  (Reine Kosten pro GB out gegen Server kosten, erhöhte Administrative kosten [jeder Server muss eingerichtet werden etc. und das wären verdammt viele...], Traffic war flatrate, allerdings nur 100Mbit/s und das reichte bei weitem nicht...)

(Bei der Umstellung waren das 7 Grafikserver, mom. müssten es wohl mind. 3 mal so viele sein [Internationale Versionen, Waschstum etc.]) (auch das ist nur geschätzt, dürfte aber wohl hinkommen)

Wenn man pro Server nicht über den 2TB-Bereich in Bezug auf Traffic hinausschießt ist Hetzner nach wie vor die beste Wahl (haben vor kurzem von 1TB inkl. Traffic auf 2TB angehoben).

Und die Anbindung der Hetznerrechenzentren ist wohl auch recht in Ordnung - vor allem aber die humanen Preise für recht aktuelle Hardware

Nicht der Traffic ansich ist bei unserer Wahl für Amazon entscheidend gewesen, sondern die Leistung in Spitzenzeiten. Wenn abends kurz vor 20 Uhr alle Welt nochmal schnell das Gemüse gießt ballert schnell mal eine hohe fünfstellige Anzahl an Requests pro Sekunde (!!) auf die Grafikserver. Und in diesen Größenordnungen überlegt ihr euch dreimal, ob ihr das selber managen wollt, oder ob ihr auf Spezialisten setzt.

@Fornax: wir führen die geschlossene Test-Runde mit gerade mal 25 Spielern durch, die natürlich kaum jemals alle gleichzeitig online sind, so dass ich hier in der Server-Auslastung noch keine besonders realistischen Werte erwarte.

Mit dem oben erwähnten Last-Generator zeigt sich aber, dass wir momentan keine 100 Spieler bedienen könnten, die gleichzeitig online sind. Da ist sicher noch Optimierungspotenzial drin, aber mir kommt das schon ziemlich wenig vor...

Ich halte unseren Entwicklungsprozess für nicht so schlecht, aber ich werfe mir inzwischen vor, zu lange auf "make it work then make it fast" u.ä. Sprüche gehört zu haben...

@hoo: Ich hab Wurzelimperium nur mal angespielt (wir entwickeln auch kein direktes Konkurrenzprodukt :-)) und muss daher dumm nachfragen: Sind die Grafikserver nur "Fileserver" oder werden da Grafiken generiert? Und ist bei euch der Traffic schwieriger zu managen als die Applikationslogik?

@alle: wenn ihr Zugriff auf den von mar1us genannten Beitrag habt - wie gesagt, würde mich sehr über ein paar Zahlen freuen!

Mit nur max 100 Spieler online pro Server kommt ihr relativ sicher in ein Problem.

Ihr müsst es einfach einmal so sehen: Wieviele Spieler pro Server online müsst ihr schaffen, bevor ihr die Serverkosten wieder drinnen habt?

Also $ pro aktiver Spieler, wieviele Spieler online pro aktiven Spieler gegenüber Kosten pro Server. Und dann habt ihr immernoch  komplett für umsonst gearbeitet. Der Wert sollte also besser deutlich höher liegen ;)

Bei 100 Spieler online, einem Aktiv zu online Quote von 10% im Peak wären das 1k User aktiv, z.B. 50/Server sind also mind. 5Cent pro User pro Monat damit ihr nur den Server rauskriegt. Betonung auf wieder nur den Server, gibt ja noch wesentlich mehr zu zahlen.

Original von PhilippC

@hoo: Ich hab Wurzelimperium nur mal angespielt (wir entwickeln auch kein direktes Konkurrenzprodukt :-)) und muss daher dumm nachfragen: Sind die Grafikserver nur "Fileserver" oder werden da Grafiken generiert? Und ist bei euch der Traffic schwieriger zu managen als die Applikationslogik?

Also das CDN bietet nur reinen Speicherplatz, daher werden darüber nur statische Inhalte ausgeliefert (Grafiken, einige CSS und Javascripte)

Bei den alten Fileservern hatten wir massive Probleme mit der Anbindung, sonst eigentlich nichts (soweit ich weiß)

@PhillipC

Wenn du nach dem Prinzipt "später optimieren" gearbeitet hast steht doch jetzt (unabhängig von der Anzahl Spieler) im Vordergrund, Profiling zu betreiben und kritischen Code zu verbessern. Das sollte man ja unabhängig einer angestrebten Userzahl machen, außer die Geschwindigkeit wirkt ausreichend (was ja offensichtlich nicht so ist). Viel bringt halt DB auslagern usw. aber mit entsprechenden Mehraufwand und da ist "make it work" als erster Satz schon richtig.

Original von MarcusSchwarz

Nicht der Traffic ansich ist bei unserer Wahl für Amazon entscheidend gewesen, sondern die Leistung in Spitzenzeiten. Wenn abends kurz vor 20 Uhr alle Welt nochmal schnell das Gemüse gießt ballert schnell mal eine hohe fünfstellige Anzahl an Requests pro Sekunde (!!) auf die Grafikserver. Und in diesen Größenordnungen überlegt ihr euch dreimal, ob ihr das selber managen wollt, oder ob ihr auf Spezialisten setzt.

Wieso denn das? Die meisten Nutzer sollten doch wiederkehrend sein - die brauchen doch die ganzen Grafiken nicht neuladen, sofern die den Cache nicht deaktiviert haben.

Original von lauscher

Wieso denn das? Die meisten Nutzer sollten doch wiederkehrend sein - die brauchen doch die ganzen Grafiken nicht neuladen, sofern die den Cache nicht deaktiviert haben.

Na ja, fx 3.0.x hatte z.B. gerade in Bezug auf den Cache das eine oder andere Manko. Mit fx 3.5 hat man das aber nun recht gut gelöst.

Original von Bringer

Original von lauscher

Wieso denn das? Die meisten Nutzer sollten doch wiederkehrend sein - die brauchen doch die ganzen Grafiken nicht neuladen, sofern die den Cache nicht deaktiviert haben.

Na ja, fx 3.0.x hatte z.B. gerade in Bezug auf den Cache das eine oder andere Manko. Mit fx 3.5 hat man das aber nun recht gut gelöst.

 Hast du dazu was konkretes?

BTW: Google sagt die korrekte Abkürzung von Firefox ist FF. Ich hoffe damit können wir dieses überholte und irreführende fx ad acta legen.

Original von Bringer

Original von lauscher

Wieso denn das? Die meisten Nutzer sollten doch wiederkehrend sein - die brauchen doch die ganzen Grafiken nicht neuladen, sofern die den Cache nicht deaktiviert haben.

Na ja, fx 3.0.x hatte z.B. gerade in Bezug auf den Cache das eine oder andere Manko. Mit fx 3.5 hat man das aber nun recht gut gelöst.

Also, sofern der Webserver korrekt eingerichtet ist, lädt auch der FF 3.0 nichts mehr nach. Kannst z.b. unter www.mediafinanz.de mal ausprobieren und dir mit Firebug angucken, was so alles nachgeladen wird, wenn du das zweite Mal auf die Seite gehst.

Original von Klaus

 Hast du dazu was konkretes?

BTW: Google sagt die korrekte Abkürzung von Firefox ist FF. Ich hoffe damit können wir dieses überholte und irreführende fx ad acta legen.

Ich mag fx, aber vor noch jemand den Glauben verliert kann ich auch gerne FF schreiben ;)

In unserem zugegeben etwas speziellen Fall (Hunchentoot Server, Weblocks Framework fürs Frontend und Steel Bank Common Lisp im Backend hatten wir grob beschrieben ein Problem, welches das genaue Gegenteil von dem im folgenden Blog beschriebenen darstellt.

http://www.west-wind.com/Weblog/posts/469125.aspx

Für lesefaule:

In dem Blogeintra geht es darum, dass gecacht wird, obwohl die Seite eigentlich überprüft werden müsste. Unser Problem war das Gegenteil - jedesmal eine Überprüfung, selbst wenn das explizit nicht gewünscht war.

Wir wiesen den Browser bzgl Bildern, CSS und js an: behalte die Dateien eine Stunde und sieh dann nach ob es eine neuere Version gibt.
FF < 3.5 hat das komplett ignoriert und jedesmal eine Anfrage geschickt, ob eine neue Version vorliegt, was uns stark ausgebremst hat.

Interessanterweise hat IE 7/8 und Opera dieses Problem nicht und es gibt auch verdammt wenig Material dazu im Web. Scheinbar haben ein paar Entwickler gemerkt das es daran liegt - aber die meisten haben die Schuld eher woanders gesucht. Allerdings wurde es bei 3.5 berücksichtigt, den Mozilla-Entwicklern ist es also aufgefallen. Vielleicht findet sich in deren Blogs/Knowlege-Base etwas dazu.

Wer es sich einfach mal selbst ansehen möchte:
thanandar.de mit beiden Browserversionen vergleichen - die meisten hier verstehen eh wesentlich mehr von Technik als ich ;)

@bloodredangel: Ja, genau das tun wir ja jetzt. Aber vielleicht hätte ich schon das Spielkonzept oder zumindest das Bedienkonzept teilweise anders entworfen, wenn ich mir vorher mehr Gedanken um diese Problematik gemacht hätte. Naja, ich denke schon, dass wir noch einiges herausholen werden, aber wie gesagt, ich wollte halt einfach mal gerne einen groben Vergleichswert haben.

Bzgl. Caching habe ich den Ansatz gewählt, dass neue Revisions meiner JS/CSS-Dateien entsprechend anders heißen. Dann kann man dem Browser nämlich sagen, dass er die Dateien cachen kann so lange er möchte. Und wenn sich was ändert, holt er sich es sofort. Spricht da was dagegen oder warum macht ihr das so nicht?

Original von PhilippC

Bzgl. Caching habe ich den Ansatz gewählt, dass neue Revisions meiner JS/CSS-Dateien entsprechend anders heißen. Dann kann man dem Browser nämlich sagen, dass er die Dateien cachen kann so lange er möchte. Und wenn sich was ändert, holt er sich es sofort. Spricht da was dagegen oder warum macht ihr das so nicht?

Das ist zwar sicherlich funktional, aber wenn ich bedenke welche weitreichenden Möglichkeiten der http-standard zur genauen Konfiguration des cachings bietet - u.A. auch was Zwischenspeicher (also z.B. proxis) angeht, so entspricht doch die Methodik der Versionierung eher dem großen Holzhammer.

Wie gesagt - es funktioniert zwar, aber es ist ein Workaround der nur ein Symptom von vielen behebt.
Unser Problem wäre damit z.B. auch nicht aus der Welt - der Client schickt ja dennoch weiterhin ständig Anfragen, anstatt einfach mal die Anweisung zu befolgen die er bekommen hat (und in unserem Fall eine Stunde mit dem zufrieden zu sein was er hat).

Edit:

Bei *sehr* hohem Trafficaufkommen kann man allerdings in jedem Fall trotzdem über eine Versionierung nachdenken. Natürlich im besten Fall eine automatisierte.

Per Cache-Header muss man dann aber auch sinnvolle Zeiten einstellen. Wir sind momentan eben bei einer Stunde für css/js/grafik - bei einem fertiggestellten Projekt könnte man daraus auch 24 Std machen.
D.h. nach dieser Zeit findet wieder eine Überprüfung durch den Browser statt, was ein ganz klein wenig serverseitige Ressourcen benötigt aber wiederum viel Bandbreite einspart.

Original von Bringer

Bei *sehr* hohem Trafficaufkommen kann man allerdings in jedem Fall trotzdem über eine Versionierung nachdenken. Natürlich im besten Fall eine automatisierte.

Rails hängt einfach den Zeitpunkt der letztden Änderung der Datei als Zeitstempel mit an den Dateinamen ran.

Einen offensichtlichen Nachteil hat die "Caching-über-Dateinamen"-Methode: Die Dateinamen sind dadurch nicht mehr schön. Für mich als jemanden der auch auf sowas Wert legt, wäre es also nichts. ;-)

Das ganze sieht dann so aus:

""
Ohne die Zahl wäre es meinem Geschmack nach auch nicht "schön". Und der Name der Datei im Repository bleibt natürlich der gleiche.

Und so steht es im Quelltext:

<%= javascript_include_tag 'prototype' %>

PHP

ist doch wurscht da am Thema vorbei.

Und wenn unbedingt perfekten Code will darf gerne bis an sein Lebensende weiterprogrammieren.

"so entspricht doch die Methodik der Versionierung eher dem großen Holzhammer."

aber die korrekte methode, die auch yahoo in einer "how to save traffic" - rede angepriesen hat. versionierung aber bitte nicht über den dateinamen, sondern über eine .htaccess, die einfach alle anfragen auf /meinenorder/wasauchimmer/ auf /dateipfad/ umleitet. dadurch kann die .htaccess in "dateipfad" angeben dass die datei sich nie nie nie ändern wird, sobald man eine neue version braucht kann man einfach "wasauchimmer" zu "wasauchimmer1.1" umändern. wird so praktiziert bei aquata, schaut mal rein. funktioniert übrigens wunderbar in allen browsern. ;)

Kannst du mir das mal an einem Beispiel erklären? Weil Caching funktioniert für CSS/JS de facto nicht in allen Browsern korrekt. Es bleibt nur Änderung der URL (Dateiname ist nur ein Bestandteil dessen).

Hatte nicht viel Zeit, daher der Block an Info, ich such mal kurz die Slides ;)

Hmm.. hab jetzt nur die Slides gefunden, die das zwar nicht genau sagen aber anderes gut beschreiben:

http://nate.koechley.com/blog/2007/06/12/high-performance-web-sites/

Wenn gewünscht, kann ich das Cachen per .htaccess und "leichter" Versionierungsnummer genauer ausformulieren - gibts bedarf?

meintest du vielleicht das?

http://developer.yahoo.com/performance/rules.html

(s. Add an Expires or a Cache-Control Header)

Ja, das fassts gut zusammen. :)

Steht zwar nicht wie mans am besten macht aber was man machen soll. Das ist das wichtigste.