spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hey,

ich habe hier im Moment einen Server vorliegen, auf den erwartet mehrere hundert Clients sich verbinden sollen.
Im Moment ist er so implementiert, dass ein Thread auf neue Verbindungen wartet und für jeden Client ein neuer Thread hinzukommt.
Zusätzlich ist es so, dass für jede Message eine neue Verbindung aufgebaut wird (und dann direkt wieder geschlossen wird). Das möchte ich abschaffen und auf eine konstante Verbindung setzen, da sowieso jede 10 Sekunden eine Nachricht geschickt wird und der Server auch auf seine Initiative Nachrichten schicken können soll.

Ich habe da nicht so viel Erfahrung drin, aber ich denke nicht dass es gesund sein wird später 600 Threads zu haben. Im Moment sind es nur ugf. 200, die aber nicht parallel laufen sondern immer erzeugt und zerstört werden (z.B. auf Programm-Ebene) wenn einer der 200 User was machen will. Sollte ich es vermeiden so viele Threads zu haben? Ich hatte neulich einen Bug dass ein TimerTask der jede 3 Minuten ausgeführt werden sollte (scheduleAtFixedRate) einfach nicht mehr gelaufen ist und der Server neugestartet werden musste. Ich weiß nicht ob das was damit zu tun haben könnte. Bisher läuft das noch relativ gut, d.h. es werden keine Verbindungen oder laufende Threads einfach gedroppt.

Mein alternativer Ansatz wäre, in einem Thread einen Selector laufen zu lassen, der bei einem Event (Accept/Read) einen Thread aus einem ThreadPool disponiert, der den Request verarbeitet und im selben Thread falls nötig eine Response sendet. Ich weiß nicht welche Modelle da gängig sind für solche Client-reichen Server. Die Gefahr die ich da sehe ist, dass ein Bottleneck dadurch entsteht, dass der Pool keine Threads mehr hat. Welche Werte sind da empfohlen als Maximum? Die Operationen in den Threads sind hauptsächlich Datenbankoperationen und Network-Stream-Writes, die dann am besten asynchron erfolgen.

Ich wäre für ein paar Meinungen dazu dankbar.

Zitat von »Tobiking«

Wenn du von asynchron wieder auf synchron wechselst gewinnst du nicht viel. Aber Datei- und Netzwerkoperationen sind inzwischen zum großen Teil asynchron vorhanden (NIO 2 & Netty). Problematisch sind meist nur die Datenbankzugriffe. Da wird ein Ansatz wie deiner mit einem Connection Pool verwendet. Da der Connection Pool sich aber nur auf die Datenbankverbindungen bezieht, ist die Größe recht beschränkt. Die Datenbank wird durch eine große Anzahl an Verbindungen nicht schneller.

Was ich mich frage ist, ob ich da am Ende nicht langsamer dran bin. Connection Pool etc. hab ich alles schon teilweise implementiert.
Mein Gedanke ist, dass wenn ich 400 Threads habe und dann plötzlich einer was von der DB will, ist das eine blockierende Operation für den Thread (?) und ein anderer kriegt dann solange mehr Zeit.
Wenn ich nur eine begrenzte Anzahl von Threads habe, und die sind plötzlich alle blockiert, profitiert keiner davon, da die anderen Requests ja noch auf einen Thread warten.

Zitat von »Tobiking«

Fängst du alle Exceptions in deinem Task? Sollte nämlich eine Exception durchfliegen, wird der Task nicht wieder gescheduled.

Nur die SQLExceptions, und da sehe ich keine in dem Zeitraum. Da passiert aber auch nichts anderes als die Verbindung und zwei Querys.

Handelt sich dabei um einen Java-Server. Asynchrones SQL wäre da also die Lösung, damit der Thread-Pool mit maximaler Effektivität arbeitet?
Ich hatte den Thread-Pool dann mit 8 Threads geplant (4 Kerne * 2 Hyperthreads) um die Architektur komplett ausnutzen. Hätte ich einen Profit von mehr Threads?

Wenn das so funktionieren würde wäre das toll.
Eine letzte Frage dazu habe ich aber noch: Ich hatte geplant die Requests teilweise zu synchronisieren (mit synchronized).
Soweit ich weiß sind einzelne Zeilen thread-sicher zugreifbar in SQL, das bedeutet aber nicht dass mein Datenmodell sicher ist.
Was ist wenn ein Request einen Query und ein davon abhängiges Update macht und zwischen beiden würde sich das Ergebnis des Querys ändern durch einen anderen Zugriff obwohl es das logisch nicht dürfte?
Daher habe ich Objects die für ein bestimmtes logisches Objekt im Business-Modell stehen (welches in der DB verwaltet wird), über die ich synchronisiere, wenn dieses Objekt bearbeitet wird und keiner "dazwischenfunken" darf. (Also sozusagen implementierung einer atomaren Operation aus mehreren Datenbankoperationen).
Wenn jetzt ein Thread auf den Monitor warten muss, weil jemand anders gerade Informationen über den User ändert, gibt er dann die Kontrolle ab? Und reiht er sich automatisch wieder ein, sobald er wieder den Lock bekommen würde? Funktioniert diese Synchronisierung also auch ohne die Threads zu blockieren?

Danke für euer Feedback. Ich denke ich weiß jetzt genug um eine Entscheidung zu treffen bzw. das dann umzusetzen. Und Goldwing danke dass du mich auf Websockets hingewiesen hast, mir ist das irgendwie entgangen, das hilft mir weiter.