Du bist nicht eingeloggt.

B2B-Realm Status

Social Networks

B2B auf Twitter
B2B auf Facebook

Bugtracker

  • »SynonymOfGod« ist der Autor dieses Themas

Beiträge: 306

Registrierungsdatum: 12.10.2010

  • Private Nachricht

1

Montag, 18. November 2013, 09:54

Server Laggs

Heyho liebe Leser,

die Zahl der spielenden Spieler steigt langsam ins unermessliche (höhö) und da stellte ich mir die Frage wie man das wohl von der Performance her bewältigen könne?
- Bessere Hardware kaufen? Joa ist möglich aber irgendwann ist man dann wieder an einem cap angekommen.
- Quellcode optimieren? Um die Performance um ca 10% zu erhöhen kann man mit 50% höheren implementierungsaufwand rechnen (schätzwerte)
- Höher skallieren? Genau hier drin sehe ich die Zukunft von großen WoW private Servern.

Also um es zu konkretisieren.. man splitted die Maps auf verschiedenen von einander getrennten Servern. So könnte man einen Heartbeat mit failover einbauen das man halt bei einem Serverausfall direkt weiter zocken kann...

Wie ich mir das vorstell: Man holt sich noch einen Zweiten Server der einen direkten anschluss zum anderen hat und über eine RDMA mit einander kommuniziert.. Da InfiniBand aber leider sehr teuer ist könnte man einen anderen weg gehen und "InfiniBand over ethernet" verwenden. Wenn beide Server im gleichen Netzwerk sind sollte dies keinerlei Probleme bereiten. Klar könnte man das auch sicherlich über ein SOAP gedöhns lösen aber das wäre nicht performant genug um die last von 1k+ Playern zu stemmen. Die Latenzen zwischen den Servern wäre nun so niedrig wie in anderen HPC-Systemen... (Ich gehe hier nicht auf UMA oder NUMA-Systemen ein da sie außerhalb der Preisklasse sind). Da die Kommunikation zwischen den Servern jetzt gegeben ist kann ein Player sich ohne Verzögerung zwischen den Maps bewegen (jedenfalls serverside). Die Kommunikation wäre damit auch geregelt.
Wenn man das System einmal implementiert hat dann sollte man eigentlich immer höher gehen können ohne wirklich nennenswerte Performanceeinbußen zu haben.

BTW: Es wäre in etwa wie hier http://www.elitepvpers.com/forum/wow-pri…s-mangos-3.html
Der hat es vor gemacht das es möglich ist ;) Klar hat er beide Nodes auf dem selben Server gestartet aber dafür habe ich oben ja schon etwas geschrieben.

MFG Ich

Es hat sich bereits 1 registrierter Benutzer bedankt.

Benutzer die sich bedankten:

ICEMANROCKT

2

Montag, 18. November 2013, 10:24

Das gibt es teilweise schon in der Form des Virtual Map Serving Systems. MangosR2 hat das implementiert, aber wenn ich mir deren Bugtracker so anschaue, bekommt man das Gefühl, dass die mit nichts anderem mehr beschäftigt sind, als verzweifelt zu versuchen die Stabilität irgendwie wiederherzustellen.

Bei Realm-Pools geht es darum Instanzen und BGs mit Spielern von verschiedenen Realms zu ermöglichen und leere Open-World Gebiete bei Bedarf mit Spielern von mehreren Realms zu bevölkern. Ansonsten bleiben die Realms aber getrennt, was meiner Meinung nach nicht unser Ziel sein sollte.

Der Flaschenhals liegt momentan bei den Map-Updates, da mit den Spielern natürlich auch die Anzahl der Maps und der zu berechnenden Map-Zellen ansteigt.
Das Problem hier ist insbesondere, dass sämtliche Map-Updates auf einem Kern stattfinden, da wir keinen vernünftigen Patch haben, der die Updates auf die Kerne verteilt. Dafür gibt es zwar bereits einen Patch, aber in der Praxis treibt dieser die CPU-Last schon bei geringen Spielerzahlen in die Höhe und sorgt für längere Aussetzer. (Wer meint den Fehler gefunden zu haben, darf sich gerne melden)

Selbstverständlich sind wir nicht untätig und sammeln stets neue Daten, werten diese aus und suchen auch im Core nach Stellen mit Verbesserungsbedarf.
FCK AFD

  • »SynonymOfGod« ist der Autor dieses Themas

Beiträge: 306

Registrierungsdatum: 12.10.2010

  • Private Nachricht

3

Montag, 18. November 2013, 11:17

Bei Realm-Pools geht es darum Instanzen und BGs mit Spielern von verschiedenen Realms zu ermöglichen und leere Open-World Gebiete bei Bedarf mit Spielern von mehreren Realms zu bevölkern. Ansonsten bleiben die Realms aber getrennt, was meiner Meinung nach nicht unser Ziel sein sollte.


Ich meinte ja kein Realmpooling und habe ja geschrieben das ich mit dem Beispiellink nur zeigen wollte das man dies durchaus verwirklichen kann. Also Die Realm sollte natürlich nicht gesplitted werden oä. sondern nur die Maps aufgeteilt werden. Es würde also bei der gleichen Datenbasis bleiben nur das man halt Maps physisch von einander trennt.


Der Flaschenhals liegt momentan bei den Map-Updates, da mit den Spielern natürlich auch die Anzahl der Maps und der zu berechnenden Map-Zellen ansteigt.
Das Problem hier ist insbesondere, dass sämtliche Map-Updates auf einem Kern stattfinden, da wir keinen vernünftigen Patch haben, der die Updates auf die Kerne verteilt. Dafür gibt es zwar bereits einen Patch, aber in der Praxis treibt dieser die CPU-Last schon bei geringen Spielerzahlen in die Höhe und sorgt für längere Aussetzer. (Wer meint den Fehler gefunden zu haben, darf sich gerne melden)

Ja dass der bottleneck die Maps sind wusste ich auch ohne das du es expliziet erwähnt hast da es bei weitem die meiste computelast zieht ;)
Das die Maps aber nur auf einen Kern laufen wusste ich nicht :) danke für diese Information ^^
Nach dem drüber lesen des Patchs stellt sich mir die frage was das für ein Mutex ist (Komme aus der Boost ecke und habe noch nichts mit ACE zu tun gehabt... Ist es ein Shared_mutex oder lockt er generell die ganze Struktur?)

Das Ganze gibt es teilweise schon in der Form des Virtual Map Serving Systems. MangosR2 hat das implementiert, aber wenn ich mir deren Bugtracker so anschaue, bekommt man das Gefühl, dass die mit nichts anderem mehr beschäftigt sind, als verzweifelt zu versuchen die Stabilität irgendwie wiederherzustellen.

Ja ich weiß das es sowas in der Art schon gibt ^.^
Ein Kollege von mir hat es meines Wissens schon einmal stabil auf ner Liverealm hin bekommen ;)
Bei dem Ging halt dann immer nur eine Map down anstatt alle ^^

Selbstverständlich sind wir nicht untätig und sammeln stets neue Daten, werten diese aus und suchen auch im Core nach Stellen mit Verbesserungsbedarf.

Ne das wollte ich euch doch gar nicht unterstellen ! Ich bin mir sogar sicher gewesen das man hier nicht untätig sitzt und Däumchen dreht ;)