[coredev]

Ursprungligen postat av Gimbo

Ok får ta och kolla på subscriber metoden, är den avancerad har du någon erfarenhet utav den? En annan grej jag kom att tänka på är om man har ett lager mellan DB dvs en webbservice som man ansluter till, den skriver i sin tur en xml fil för varje spel när spelet är klart och får status finished så lägger man in datat i DBn och raderar xml-filen?

Det kan vara en mycket bra lösning. Databaser är bra på att sortera, gruppera, och manipulera data - man tänker ofta databas när man skall lagra information men i ditt fall skulle fil som komplement kunna vara mycket snabbare och mer ändamålsenligt.

Du kanske till och med skapar en rad i databasen vid spelets början och så heter filen radens id-nummer + .xml. Kanske kan du skippa XML för att snabba upp det ytterligare på servern, Nyckel=Värde på en ny rad räcker ofta mycket långt. JSON kan vara ett mellanalternativ om du behöver lite mer struktur.

En ytterligare optimering är att du skriver en egen serverapplikation i t.ex. c++ istället för att använda en webserver + ett scriptspråk. :-)

[Gimbo]

Tror du att det skulle räcka med en server då, att man har en dedikerad server med 32gb i ram och mysql installerad på den? är xml snabbare än txt filer om man kör den här varianten? eller spelar det ingen roll om man kör xml eller txt filer?

Så tanken blir så här man har en tabell som heter Games och med tabellerna enligt nedan:
|Games|
gameID
Player1
Player2
TimeStamp
Chat

sedan heter txt eller xml filen det som står i gameID.txt man lagrar dessa txt filer lokalt i en mapp när ett spel får status avslutat så skriver man in det datat i databas tabellen och deletar txt filen?
Vad skulle jag kunna göra med JSON i det här sammanhanget aldrig använt det?
Vad skulle serverapplikationne göra? skulle dessa skapa xml filerna eller vad är tanken med serverapplikationen? Har du någon erfarenhet av detta och skulle kunna hjälpa till naturligtvis mot betalning.

[captaindoe]

Jag skulle inte placera kolumnen 'Chat' i din Games tabell.
Jag tror personligen det blir bättre om du skapar en tabell enbart för chatten.

|Chat|
gameID int primary
player int/var # i denna kolumn har du antingen användarens medlemsid, eller spelarens namn.
text varchar

Hur har du tänkt att din tabell ska agera? Ska en ny rad läggas till i databasen för varje speländring, eller har du tänkt uppdatera den befintliga raden?

Jag tror personligen att du måste spendera mer tid på att effektivisera din nuvarande kod, databashantering, och eventuell cachning istället för att fundera hur kraftig server du behöver.

[Clarence]

Att implementera en subscriber-modell är inte speciellt avancerat. Men förstår du dig inte på den kommer du givetvis inte kunna skriva koden ännu. Vill du göra det enkelt för dig kan du använda node.js med socket.io och sedan på klientsidan antingen använda ett bibliotek för websockets eller kommunicera genom en osynlig webview.

Att skriva till en mellanlagring i form av en XML-fil/JSON förstår jag inte riktigt anledningen till. Har du en väl konfigurerad sql med buffring av writes kommer du få mycket bättre throughput på den än att manipulera ett json/xml-dokument varje skrivning.

Som captaindoe är inne på tror jag också du försöker fokusera för mycket på hur kraftig burk du behöver. Om du istället fokuserar på att skapa en effektiv kod som du dessutom kan skala upp till flera servrar utan problem så lägger du tiden på rätt ställe. Du bör inte försöka dimensionera för 1M användare från start, du bör ta de enkla stegen som förenklar det problemet senare.

[pelmered]

Intressant tråd!

Till att börja med vill jag säga att det är väldigt svårt att lyckas ordentligt med mobilappar i dagens stenhårda konkurrens. Därför tycker jag att man rent tekniskt ska göra det så enkelt för sig möjligt i den första releasen utan att göra för mycket avkall på kvaliteten hos användaren för att se hur det går med appen. Det handlar väldigt mycket om tur och timing för att lyckas, samt att givetvis ha en bra app som folk vill ha. Det gäller att få en bra start. Fingertoppskänsla kan reducera turkfaktorn en del, men inte eliminera den.

Utifrån detta skulle jag ge dig följande råd:
Investera inte för mycket pengar och tid på att göra det perfekt tekniskt. Lansera och testa först och ta tag i problemen efterhand som de uppkommer, gärna med lite framförhållning så försök vara förutseende.

Kör på som du tänkte ifrån början, fast du kanske ska justera ned pull-tiden en del(testa dig fram vad som fungerar, men du kan ju börja med den ganska låg och sedan tycka ut en uppdatering om belastningen blir hög). Ha dock i åtanke att du så småningom behöver ändra till en subscriber/push-teknik.
Jag tror du kan komma upp upp hyfsade volymer om du väljer rätt teknik på serversidan. Mitt förslag där är följande:
- Kör MySQL i botten om det är det du är mest bekväm med(tänk på index och struktur).
- Framför databasen kör du memcached(eller något annat cachesystem) för att hantera all aktiv data.
- För att göra det enkelt för dig kan du kör med en webbserver för att hantera kommunikationen. Du behöver då en webbserver som kan hantera många samtidiga användare och många anslutningar. Mitt förslag här är Nginx.

Hur det sedan ska fungera är att när en spelare gör ett drag så sparas detta givetvis ned i databasen. Men du sparar även detta direkt i memcached(sätt en ganska lång time-to-live/cachetid så att den inte behöver refreshas hela tiden, t.ex. 1 dag. optimera detta efter hur appen fungerar). När motspelarens app ansluter till servern kollar du i memcached om datan finns där, vilket den bör göra om inte uppdateringen var mer än ett dygn(cachetiden) sedan.
Med det här systemet kommer det nästan bara vara updates/inserts emot databasen och det finns inget jättebehov för att detta görs i realtid heller(viss fördröjning i skrivningarna är helt okej). Läsningarna kommer normalt varken röra databasen eller hårddisken(om du kör någon opcode cache t.ex. APC) så det kommer inte kräva mycket prestanda för höga volymer.

För att göra hårdvaran billig(vid små volymer) och skalbar bör du som sagt köra någon cloud-lösning. Då kan du skala upp din server väldigt enkelt vid behov. När det inte längre räcker med en server kan du klona din server till flera och sätta upp en lastbalanserare. Ett första enkelt steg innan det kan vara att separera ut MySQL-databasen till en egen server.

Har du lite erfarenhet av detta sätter du upp detta på en timme. Logiken på servern kan du snabbt koda ihop i t.ex. PHP.

Med det här systemet kan du definitivt hantera tusentals användare på en ganska enkel server. 40-50 000 hits per sekund bör gå att få till.

[ah-berg]

Att skriva direkt till databasen är verkligen inge bra ide. Det som blir mer populärt numera att lägga ut vissa funktioner till andra som egentligen inte vill hålla på med, Apple har t.e.x game center för att kunna bygga enklare typer av spel utan att behöva ha egna servrar. Sen är det som alltid att ska man bygga något bra skalbart system så kräver det tid och pengar.

[Wojt]

Skulle kollat på Amazon AWS för skalbarhet. Plus att jag tror det även finns "Iphone database hosting" för folk som vill att någon annan sköter allt det och kan fokusera på appen.

[RobertBrewitz]

Ursprungligen postat av Gimbo

Hej,

Håller på att utvecklar en iphone app som är ansluten till en databas, varje app kommer att pinga servern 1gång per sekund

Tips är att köra åt andra hållet, ha "streamade kanaler" på servern som apparna kan sitta och lyssna på istället. Jag vet dock inte hur (web)sockets fungerar i native iphone appar, endast kört websockets själv.

Lätt att sätta upp med Juggernaut (https://github.com/maccman/juggernaut).

Annars har jag som tumregel på Amazon AWS, 10-50 unika simultananvändare (50 är ganska stabilt om det är t.ex. ett forum eller community) per process per kärna, beroende på applikationens komplexitet/storlek. RAM är oftast inget problem innan saker ska börjas cachas i minnet.

Med vänlig hälsning,
Robert

[Gimbo]

Tack för era svar!
Det stämmer att det är svårt att lyckas med appar men har en känsla gällande just den här appen och därför vill jag göra rätt från början, för om spelarna märker av störningar i systemet så tappar den värdighet och man lägger undan den utan att rekomendera den till sina vänner.

Jag valde att köra en sån här lösning vad gäller serverskde:

1front end maskin som finns i en molntjänst (anl till att jag inte kör amazon eller andra cloud lösningar helt och hållet är att jag behöver bra diskar)

Sedan har jag 2klustrade db- servrar med mysal på bakom webbfronten, och det är rätt så kraftiga maskiner jag har.

Kör för tillfället med vanliga sql satser men funderar på att gå över till memcache och NoSQL om det visar sig att appen växer, på så sätt kan kag både efffektivisera kod och miljö.

Jag hoppas ovan är en bra lösning, då är vi inga gurus på att skriva bra sql'er och undrar vad det är man bör tänka på vid vanliga select, updates och inserts till enskilda tabeller utan några avancerade joinar?

[pelmered]

Ursprungligen postat av Gimbo

Tack för era svar!
Det stämmer att det är svårt att lyckas med appar men har en känsla gällande just den här appen och därför vill jag göra rätt från början, för om spelarna märker av störningar i systemet så tappar den värdighet och man lägger undan den utan att rekomendera den till sina vänner.

Jag valde att köra en sån här lösning vad gäller serverskde:

1front end maskin som finns i en molntjänst (anl till att jag inte kör amazon eller andra cloud lösningar helt och hållet är att jag behöver bra diskar)

Sedan har jag 2klustrade db- servrar med mysal på bakom webbfronten, och det är rätt så kraftiga maskiner jag har.

Kör för tillfället med vanliga sql satser men funderar på att gå över till memcache och NoSQL om det visar sig att appen växer, på så sätt kan kag både efffektivisera kod och miljö.

Jag hoppas ovan är en bra lösning, då är vi inga gurus på att skriva bra sql'er och undrar vad det är man bör tänka på vid vanliga select, updates och inserts till enskilda tabeller utan några avancerade joinar?

Vad använder ni för teknik för att svara på alla requests ifrån klienterna(språk och webbserver, om någon)?

Jag skulle hur som helst starkt rekommendera att ni mellanlagrar så mycket som möjligt i något cachesystem som, t.ex. memcached. Det är väldigt enkelt att implementera.

Det finns lösningar för att köra NoSQL i MySQL också med riktigt bra prestanda. Då kan man köra vanliga SQL-queries, fast med vissa begränsningar.