[Java] MySQL Threaded of Pooling ?

[xehbit]

Hallo Tweakers,

Nu ik me al een enige tijd bezig hou met Java wou ik eens gaan kijken naar MySQL in java. Hier valt ontzettend veel informatie over te vinden op wat voor manieren het kan. Veel goede voorbeelden gevonden maar ook minder goede websites / blogs.

Ik zie ook vaak voorbij komen Threaded MySQL of Pooling MySQL. Als ik het goed begrijp is threaded mysql een thread starten per query? Maar hoe word de info terug gegeven aan de applicatie als die threaded draait. Je kan dan geen return blahblah; doen. Bij pooling kan dat weer wel, die heeft een aantal connectors klaar staan die je kan gebruiken, maar als de MySQL server een beetje traag reageerd loopt de applicatie ook vast.

Dus (als ik het goed begrijp) is threaded beter dan pooling bij een langzame MySQL server. Klopt dat ?

[Gomez12]

Grote vraag is over het algemeen wat wil je doen zonder data? Is je app dan nog wel zinvol of kan de gebruiker toch niets doen en moet die toch wachten?

Als je threading wilt gaan gebruiken voor een langzame server dan zou ik het niet doen, het enige wat je dan doet is meer query's naar de server sturen waardoor die nog trager wordt.

Als je probleem een langzame server is, verhelp dat probleem dan en ga er niet omheen werken met methodes die nog meer problemen veroorzaken.

[xehbit]

Het betreft een Javaserver die als gameserver moet gaan draaien (Java is de keus van de klant). Die moet wel via sockets de verbinding gewoon snel houden en speler posities blijven versturen.

Dus de gebruiker mag eigenlijk niet wachten.

[Gomez12]

Dragon707 schreef op zaterdag 29 december 2012 @ 00:33:
Het betreft een Javaserver die als gameserver moet gaan draaien (Java is de keus van de klant). Die moet wel via sockets de verbinding gewoon snel houden en speler posities blijven versturen.

Dus de gebruiker mag eigenlijk niet wachten.

Ik snap dat de gebruiker niet mag wachten, maar de grote vraag is wmb nog steeds wat moet er gebeuren als de gebruiker toch moet wachten op een trage mysql server?

Heb jij dan logica achter de hand om de gebruiker toch door te laten spelen en de andere posities via iets van AI te voorspellen of blijven de andere spelers dan simpelweg staan en "verspringen" ze opeens?

Zou het enkel gaan om scores oid dan zou ik gelijk zeggen : threaded (het resultaat is niet kritiek en de gameplay kan ongestraft doorgaan)
Maar als je ook posities etc gaat doorgeven ("kritieke info") dan zou ik pooled gebruiken want adhv daarvan kan je anti-cheating regels toepassen (een gebruiker mag niet van positie "verspringen" etc).

In principe moet je wel altijd een 2e thread aanmaken voor alles naast de gui-thread, maar binnen die 2e thread zou ik dan simpelweg pooling gebruiken.

[supreme tweaker]

Hoe je een DB in een gameserver inbouwt is denk ik niet zo relevant voor de TS. Wat wel interessant is, is hoeveel connecties/connectieobjecten je gaat bijhouden. Ik zou kiezen voor Pooling, omdat je op die manier connecties kan hergebruiken en dus tijd bespaard. Met de nadelen van pooling ben ik niet bekend, maar ik kan me ook voorstellen dat je niet altijd een "voorraad" van x connecties wil open hebben staan, als de gameserver niet zoveel doet. Ik weet niet precies hoe sql connectors daarmee omgaan.

Daarnaast; Zowel bij pooling als threading zal je op een query resultaat moeten wachten van een DB server. Hoe je dat soort latencies opvangt in je communicatie is iets waar je over na moet denken, maar geen rocket science. Daarnaast moet je je afvragen wat een real-world scenario is.

[ Voor 22% gewijzigd door supreme tweaker op 29-12-2012 01:33 ]

[Jegorex]

Als het gaat om een game server dan is het niet zo belangrijk op welke manier je de data opslaat.
De gegevens van spelers die naar andere spelers moet worden doorgestuurd moet je echter niet eerst in de database opslaan en dan weer uitlezen.

[Cobalt]

Welke Java server gebruik je?

[ Voor 81% gewijzigd door Cobalt op 29-12-2012 11:47 ]

[CH4OS]

Dragon707 schreef op zaterdag 29 december 2012 @ 00:33:
Het betreft een Javaserver die als gameserver moet gaan draaien (Java is de keus van de klant).

Het is offtopic, maar Java gaan gebruiken "Omdat de klant het vraagt" is imo geen reden om Java "dan maar" te gaan gebruiken.

Als ik je TS zo lees, is programmeren in Java nieuw voor jou / jullie. Wellicht is het dan ook een idee om even te verdiepen in Java zelf tov andere programmeertalen (eventueel in combinatie met gaming) en de voor- en nadelen helder te krijgen. Als er dan teveel haken en ogen kleven aan Java, kun je altijd met een tegenvoorstel komen richting je klant en hen waarschuwen als ze tóch bij hun keuze voor Java blijven.

De klant wil immers een goed product wat uiteindelijk dan ook goed werkt en presteert (zoals men wil), niet in een product wat compleet is gemaakt naar de wensen van die klant en vervolgens niet goed lijkt te werken of presteren. Vervolgens ben jij of zijn jullie de gebeten hond, want jij/jullie hebt/hebben dan geen adviserende rol gespeeld of in ieder geval niet tijdig op de rem getrapt.

[MLM]

Een gameserver moet meestal voldoen aan een respons-tijd om de game-ervaring goed te houden. Het is nogal afhankelijk van het type game, wat acceptabel is. Een FPS-server mag je toch wel 20-30 update's per seconde verwachten (tientallen milliseconden per respons), maar en webgame server kan best een seconde duren, dus dat is nogal een verschil.

In welke mode je database ook draait, die moet wel alle aanvragen verwerken. Dus de hoeveelheid werk die uitgevoerd moet worden, is hoe dan ook hetzelfde. Meer threads is meer overhead (context switching, meer contentie op locks), dus dat is slechts in enkele gevallen nuttig (als je pool vol zit met "langzame onbelangrijke" taken, terwijl je "belangrijke korte" dingen in de wachtrij hebt staan). Of die situatie voorkomt, lijkt me nogal afhankelijk van je database en je queries

Zoals met alle performance-related dingen, meten is weten Maar ik zou met pooling beginnen tenzij je merkt dat dat een probleem oplevert.

[ACM]

Ik denk dat je het beste kan beginnen met een algemene connection-pool die automatisch voor je wordt bijgehouden. Mocht MySQL bottlenecks veroorzaken, dan moet je die waarschijnlijk toch per losse bottleneck oplossen en bovendien zal de aanpak per keer verschillen.

Het kan goed zijn dat je bijvoorbeeld onderscheid kunt maken tussen updates/inserts/deletes die belangrijk zijn en updates die best een paar seconden later mogen gebeuren. Die laatste groep zou je dan met een producer/consumer-opstelling kunnen verwerken (bijv via een (message) queue).
Of wellicht update je informatie die zo snel daarna weer verandert dat het uberhaupt niet loont om het (elke keer of direct) in de database bij te werken, maar waarvan je het domweg in ram-geheugen bij kan houden.

Voor het selecteren van data geldt iets soortgelijks. Wellicht is bepaalde informatie zo vaak nodig, dat je uberhaupt de roundtrip naar de database liever niet wilt maken. Je kan dergelijke informatie dan mogelijk cachen in je serversoftware zelf en zo veel sneller de gegevens beschikbaar hebben.

Met dergelijke strategien ga je waarschijnlijk meer performanceproblemen wegnemen dan een algemene keuze om wel of niet per query/gebruiker een losse thread/connectie naar MySQL te maken.

[xehbit]

Bedankt voor de reacties allemaal, het betreft inderdaad een FPS game.
Wij gaan proberen om een testcase (strestest) te maken met pooling van de MySQL connecties.

Op dit moment hebben we ook een thread waar we sql query's queue'n die we pas later nodig hebben. Het gaat dan om de grote data query's en loggen van gegevens. Dit heeft al een hoop lag verholpen.

Sommige data gaan we niet opslaan in een database maar in een flatfile op de lokale schijf. (minimap render voor de browser). Ook dit is nu een stuk sneller!

[ACM]

Dragon707 schreef op zaterdag 29 december 2012 @ 16:17:
Sommige data gaan we niet opslaan in een database maar in een flatfile op de lokale schijf. (minimap render voor de browser). Ook dit is nu een stuk sneller!

Is het zoveel data dat je het niet in RAM wilt (kunnen) houden? Het is vrij eenvoudig om een paar GB aan data in je JVM te alloceren (en veel datastructuren zijn helemaal hooguit een paar MB) en dat is mogelijk nog wat sneller dan een bestand. Vooral omdat je de objecten precies op de goede manier kan bewaren, in plaats van vormen van conversie nodig te hebben.

[matthijsln]

Geen enkele FPS gameserver slaat real-time speler posities op in een (rdbms) database. Als de server crasht wordt iedereen gewoon gekicked. Sla hoogstens stats/achievements oid op in de db of dingen die niet real-time zijn maar die je wel wilt bewaren.

@CptChaos aan z'n post history te zien heeft de TS alle andere talen al geprobeerd