|
 eMail Suche Impressum
|
Next: 8. Zusammenfassung und Ausblick Up: MMPG-P2P Previous: 6. Verwendung des Frameworks Contents Index
7. Performanzmessungen
Im vorliegenden Kapitel soll erläutert werden, wie die vorgestellte Implementierung
auf Performanzkriterien geprüft wurde. Zur Erleichterung dieser Aufgabe wurden
einige Skripte entwickelt, die automatisierte Clients auf fernen Rechnern starten können.
7.1 Tests auf DSL-System
Das System wurde in der in Abbildung 7.1 gezeigten Konfiguration entwickelt und ständig nebenbei getestet. Dabei wurde auch auf diverse freiwillige Testpersonen zurückgegriffen, die über die DSL-Anbindung aus dem Internet an das System angeschlossen waren. Die plattformübergreifende Lösung in Form eines ausführbahren Java-JARs machte es Anwendern leicht, die Demo zu starten.
7.1.1 mit realen Spielern
Über Wochen hinweg wurden mit mehreren Spielern aus dem Internet Testspiele absolviert. Die Performanz des Systems war bei allen Tests lediglich durch die Netzwerkbandbreite des RegionControllers in Richtung Internet limitiert.Ein verbundener Client verursachte einen Verkehr von ca. 10 KByte/Sek., was angesichts meiner DSL-Anbindung mit einem Upstream von 64KByte/Sek. die Anzahl auf etwa 5 Clients beschränkte. Darüber hinaus ruckelte das Spiel spürbar, denn die anfallenden Datenmenge konnte nicht mehr vor dem nächsten Tick übertragen werden. Einige BotPlayer konnten zusätzlich zu den menschlichen Spielern in das Spiel eintreten, da diese die internetseitige Bandbreite nicht schmälerten.
7.1.2 mit BotPlayern
Für automatisierte Tests habe ich eine Klasse BotPlayer (Details siehe Abschnitt 6.1.5) implementiert, die einfache Spielzüge ausführt und gelegentlich auf Objekte feuert. Somit kann durch solch einen Bot ein einzelner Client simuliert werden.Bei Leistungstests auf dem Rechner ``media'' 7.1 wurde etwa mit 20 BotPlayern die Leistungsgrenze der CPU erreicht. Wurden weitere BotPlayer gestartet, dann konnten einige RegionControllerThreads die Ticks nicht mehr zuverlässig berechnen.
7.2 Tests im Rechner-Pool
Der Fachbereich stellte einen Zugang zu diversen Pool-Rechnern zur Verfügung. Diese konnten für einige Stabilitäts- und Skalierungstests genutzt werden. Die Ergebnisse sollen hier zusammengefasst werden.
7.2.1 ServerStats
Wie im Abschnitt 5.5.9.1 beschrieben, wird ein ServerStats-Protokoll angefertigt. Das Protokollierungsinterval wurde auf 2000ms gesetzt, um den Verlauf der Werte in einer hohen Auflösung darstellen zu können. Eine grafische Auswertung dieser Daten wurde mit Gnumeric [10] erzeugt.
7.2.2 Grundsätzliche Vorgehensweise
Die Performanztests werden nach folgendem Schema durchgeführt.- Auf dem Server wird der Server-Prozess des MmpgP2P-Systems gestartet. Somit läuft hier auch der initiale RegionController. Die Spielewelt wird mit einer Tilesize von 2000 konfiguriert und hat die Größe 200.000x200.000.
- Als Clients für das System kommen Prozesse auf acht Pool-Rechnern im LAN zum Einsatz. Zunächst werden auf jedem dieser Rechner über ein Skript (siehe Abschnitt 7.2.3) zwei BotPlayer mit RegionControllern auf den Ports 18900 und 18901 gestartet. Somit stehen dem Server 16 freier RegionController auf verschiedenen Rechnern zur Verfügung. Der BotPlayer führt automatisierte Spielzüge durch und simuliert somit einen aktiven Client.
- Als nächstes werden kontinuierlich zusätzliche Clients simuliert,
indem erneut auf jedem der Pool-Rechner ein weiterer BotPlayer gestartet wird.
Dies wird so lange fortgeführt, bis die Pool-Rechner nicht mehr in der
Lage sind, weitere Prozesse zu starten. Jeder vierte BotPlayer wird mit
einem RegionControllerThread gestartet, die übrigen mit dem Parameter
norc.
Dieser Schritt wird so lange wiederholt, bis der Server nicht mehr performant läuft oder ein schwerwiegener Fehler auftritt, der das System zum Absturz bringt.
7.2.3 Skripte zum Starten der Clients
Um das Starten von Clients zu automatisieren, wurden Sktipte entwickelt, die verschiedene Aufgaben übernehmen.- startManyClients.sh
Per SSH wird eine Verbindung zu jedem Pool-Rechner aufgebaut und dort das Script startBots.sh aufgerufen (siehe folgender Abschnitt 7.2.3). Ein Paramterrcport sollte
bei einem Aufruf mit angegeben werden, damit auf den Pool-Rechnern mehrere
RegionController starten können.7.2
- startBots.sh
Dieses Skript wird über ssh auf verschiedenen Pool-Rechnern aufgerufen. Es kümmert sich darum, dass ein BotPlayer mit einer zufälligen Verzögerung zwischen 1 und 60 Sekunden startet und zum Server verbindet. Hängt man den Parameternorc an, dann startet der BotPlayer keinen
RegionController.
Mit dem Parameter
nr kann man dafür sorgen, dass mehrere Instanzen
von BotPlayer innerhalb einer Java-VM 7.3gestartet werden. Ein zusätzlicher Parameter interval
kann zum Festlegen eines Intervals (in Millisekunden) zwischen zwei zu startenden Instanzen
genutzt werden. Standard sind 10 Sekunden Wartezeit zwischen zwei Instanzen.
Um nur eine gewisse Anzahl an RegionControllerThreads zu starten, benutzt man den Parameter
rcnr. Dann werden so lange BotPlayer mit RegionController
gestartet, bis dieser Wert erreicht ist. Der Port, auf dem der jeweilige RegionController
bindet, wird dabei bei jeder Instanz um eins erhöht, ausgehend von dem konfigurierten
Port.
Einige Poolrechner konnten bereits nach dem Start von ca. 20 BotPlayern nicht mehr genügend Rechnenleistung für weitere BotPlayer aufbringen. Eine Verbindung per SSH war nur noch nach einer Wartezeit von bis zu einer Minute möglich. Daher wurde in der Socket-Verarbeitung ein Befehl KILL eingebaut. Verbindet man sich mit telnet auf einen der von BotPlayer gestarteten Threads und gibt KILL ein, dann wird über System.exit() die Java-VM beendet. Damit kann man blockierende Prozesse schnell beenden.
7.3 Auswertung der gesammelten Daten
Die gesammelten Statistiken (siehe Abschnitt 5.5.9.1) wurden mit Gnumeric [10] zu Diagrammen zusammengefasst. Es folgen einige Diagramme, die das Verhalten des Systems skizzieren sollen.
7.3.1 Erste Testreihe
Die Spielewelt wurde auf 200.000x200.000 Punkte mit einer Kachelgröße von 2000 eingestellt. Zur Befüllung der Welt wurden 2000 statische und 1000 bewegende Objekte eingefügt. Das Client-Limit pro Region wurde auf 20 eingestellt.BotPlayer wurde angewiesen, 28 Clients und 4 RegionController pro Pool-Rechner zu starten. Dies kann man in den folgenden Diagrammen nachvollziehen. Zwischen zwei Client-Starts werden 20 Sekunden vergangen gelassen.
7.3.1.1 Verbundene Clients und Auslastung
In Abbildung 7.2 sind drei wichtige Kurven zu sehen. Zum einen die Anzahl der mit dem System verbundenen Clients (clients) und zum anderen die Systemlast (load*5). Die dritte, oberste Kurve (conns) gibt die Anzahl der bisher eingegangenen und verarbeiteten Verbindungen an. Diese Zahl enthält Login-Verbindungen eines Clients sowie regelmäßige Verdingungen der RegionController.
 |
Der steile Anstieg der Systemlast-Kurve bei Log-Eintrag 260 ist dadurch zu erklären, dass vorher einige Splittings durchgeführt wurden (zu sehen in Abbildung 7.3). Die Verschiebung der Systemlastkurve in X-Richtung rührt daher, dass /proc/loadavg grundsätzlich verzögerte Werte liefert.
7.3.1.2 Freie und benutzte RegionController
Abbildung 7.3 stellt die verfügbaren sowie die bereits verwendeten RegionController der Anzahl an verbundenen Clients gegenüber. Somit sieht man hier, wie sich das Verbinden neuer Clients auf das Splitting der Regionen auswirkt.
7.3.2 Zweite Testreihe
Die Größe der Spielewelt wurde nicht geändert. Jedoch wurde die Spielewelt mit 3000 statischen und 2000 bewegenden Objekten gefüllt. Das Client-Limit pro Region wurde auf 8 Spieler pro Region gesenkt, so dass mehr Splitt-Vorgänge stattfinden sollten. Das sollte insgesamt die Last des Servers erhöhen, da sich letztendlich mehr Regionen ergeben und somit auch mehr Regions-Wechsel der Avatare stattfinden.BotPlayer wurde angewiesen, 15 Clients und 10 RegionController pro Pool-Rechner zu starten. Dies kann man in den folgenden Kurven nachvollziehen. Die Clients sollten nun jedoch in einem Intervall von 10 Sekunden hintereinander gestartet werden.
 |
Next: 8. Zusammenfassung und Ausblick Up: MMPG-P2P Previous: 6. Verwendung des Frameworks Contents Index
designed using WebCut - Copyright (c) 2001-2008 by Markus Sinner