[Gimbo]

Appen är så gått som klar och den är ansluten mot mySQL etc, så att ändra hela tänket nu skulle kännas som en rejäl uppförsbacke men om det är vad det krävs så får man helt enkelt tänka om.

Hur skulle en VPS lösning se ut? skulle vi kunna vidare på samma ätnk med VPS?

[Digitum]

Då förstår jag vad du vill uppnå. Jag är ingen fena på det direkt men det är helt klart nån push-teknik du skall använda. Då behöver du bara skicka data från servern till anslutna klienter när det finns data att skicka.

Hur som helst så är det inte webbservern som skall hantera dessa anslutningar utan dedikerade spelservrar. Själva anropen och inloggningarna skulle kunna, men inte nödvändigtvis, ske via webbservrar.

Men ett tips om man vill att klienten skall polla med jämna mellanrum är även att skicka med lite data tillbaka som talar om hur hög belastningen på servern är, då kan klienterna dr ut lite på pingintervallet när belastningen är hög.

[coredev]

Ursprungligen postat av Gimbo

Appen är så gått som klar och den är ansluten mot mySQL etc, så att ändra hela tänket nu skulle kännas som en rejäl uppförsbacke men om det är vad det krävs så får man helt enkelt tänka om.

Hur skulle en VPS lösning se ut? skulle vi kunna vidare på samma ätnk med VPS?

VPS är ett alternativ till att köpa en egen server. Istället för att ha en fysisk burk så hyr du en virtuell burk. Behöver du mer prestanda så klonar du bara din VPS och vips så har du mer kapacitet.

Mitt råd är du skall köra igång som det är. Skulle din app bli jättepoppis så tar du det då. :-)

[Clarence]

Ursprungligen postat av Gimbo

Appen är så gått som klar och den är ansluten mot mySQL etc, så att ändra hela tänket nu skulle kännas som en rejäl uppförsbacke men om det är vad det krävs så får man helt enkelt tänka om.

Hur skulle en VPS lösning se ut? skulle vi kunna vidare på samma ätnk med VPS?

Så länge du är med på att du har en lösning som kommer bli onödigt dyr om du får mycket användare så visst, spinn vidare. Men var beredd på att stöta på stora problem om du får viral spridning.

En VPS-lösning läggs optimalt på ett moln med ordentligt med on-demand instanser lediga vid varje tillfälle, t ex amazon eller rackspace. I ditt fall behöver du egentligen ingen replikering mellan VPSerna utan ett spel behöver bara kommas åt via en instans. Nästa instans kan du dirigera andra spel mot. Applikationen måste då vara medveten om vilka instanser som får vilka spel. För två servrar kan du t ex låta jämna/udda ids hamna på varsin server. Sen behöver du användarna på en central server (som i sin tur kan replikeras för att öka prestandan) samt en id-generering centralt så att id på ett spel blir unikt över alla instanser och därmed kan dirigeras rätt. Vill du läsa på lite om fenomenet brukar det kallas database sharding och är ett väldigt vanligt tillvägagångssätt för större datamängder eller last. Märk väl att du måste ha en sharding som du kan ändra i realtid för att du ska ha ordentlig nytta av det.

Försöker du med replikering av all data till alla instanser kommer du vid en viss last stöta på större och större fördröjning i replikeringen. Till slut kommer det behöva lösas med flera servrar som i en hierarki sköter replikeringen - väldigt mycket overhead, låg fault-tolerance och väldigt omständigt att hantera. Främsta anledningen till denna utgång är att du endast har en tråd till replikeringen i MySQL medans writes till mastern använder flera trådar.

[patrikweb]

Grunden till börja bygga en skalbar lösning från början är att börja med sätta upp en SLB.

Sedan kan du bygga på med nya MySQL / Webservrar bakom efter belastnings behov.

Beroende på nivå av MySQL kan du sätta upp Galera Cluster, exempelvis Galera Multi-Master Replication lösning. Vilket har en hel del fördelar.

Sedan om man har väldigt mycket ram så du har DB i minnet bara samt väldigt fet write cache så spelar diskarna väldigt liten roll i det hela. Då är det mer fråga om CPU för hantera frågorna.

[Gimbo]

Tack för alla svar, det var inte så lätt som man trodde, har tittat lite på det här med cloud, man verkar kunna öka det både i bredden och längden med claud, fast vågar inte ens tänka tanken på hur mycket det skulle kosta med de volymerna jag räknar på. Såg att citynetwork hade en claud lösning men som sagt vet inte om man vågar köra på Claud, då sitter man fast där i molnet och är tvungen att öka hela tiden och kostnaderna ökar proportionenligt.

[Gimbo]

@Clarence, har tittat på en klustrad variant med 2mysql maskiner och en front end och så kör jag memcache på mysql maskinerna men det är som du säger att det kommer skapa problem, du nämnde något med en applikation för att hålla datat och sedan när det är klart så skriver man till DBn hur skulle det se ut i det här fallet? Vår app går som sagt ut på att då man lägger en bricka så uppdateras DBn med brickan, när man startar ett spel och utmanar en annan person så initierar vi en rad i en tabell med GameId etc, kan man då via den här applikationen du nämner lagra all brick data och sedan när spelet är slut så trycker man in det i DBn?

Frågan är då hur klarar den här applikationen att hantera all den här datan är det inte samma sak som att skriva till DBn? kommer kräva ett riktigt stort minne att hålla 1M spel som konstant pingar applikationen i shack eller är jag helt ute och cyklar?

Är beredd på att ändra i tänket och koden för att få det här att lira, med din lösning skulle det räcka med en kraftig maskin?

[Clarence]

Att ha en subscriber-modell innebär ingen skillnad i hur du lagrar informationen (db, memcache). Det innebär inte nödvändigtvis heller någon förändring i hur du hämtar informationen (db, memcache). Däremot så gör det ofantlig nytta i att minska antalet requests till din applikation.

Med en pull-struktur, liksom den du beskriver, måste varje användare gå till din server och ställa en fråga för varje möjlighet som ska ges för uppdatering.

Med en push-struktur med subscriber-modell ansluter de till din server i början av spelet. Varje gång någon lägger en bricka skickas även det meddelandet in till din push-server (eller om den läser ny brickor t ex var 0.1 sekund). Denna skickar sedan ut meddelandet till de som är registrerade som mottagare (i ditt fall en motståndare) över den redan öppna anslutningen utan att en besökare behöver belasta din server med ett extra request för varje tick i uppdateringen. Den skickar bara vad den behöver skicka, när det ska skickas, bottleneck här ligger i antalet spelare istället för hur snabbt saker ska hända. För en snabb lösning, som jag dock är osäker på hur väl den skalar, titta på socket.io och subscriber model.

1M samtidiga spelande kommer du aldrig klara på en burk, oavsett metod eller kod.Men du har en väldig overhead om du ska låta dina användare pinga en gång i sekunden jämfört med att använda en push-modell.

Du kommer inte lyckas skala till en miljon samtidiga användare utan extern expertis om du inte gör ett rejält djupdyk i skalbarhet och prestanda av liknande applikationer. När man kommer upp i sådana nivåeer är det också viktigt att ha finansieringen klar för sig. Det är därför de flesta stora startups har investerare, inte för att begränsa sin handlingsförmåga.

[patrikweb]

Allt är en kostnadsfråga i grunden, tekniskt kan du ha 100 servrar i ett mySQL cluster som i sin tur skalar väldigt bra i prestanda. Men är inte gratis.

Sedan kan jag nog se stora problem med en push-modell med om det handlar om flera 100 tusentals aktiva spelare/anslutningar. Då tror jag att man får dela upp det i "små cluster/grupper" där olika användare hamnar i olika cluster grupper som är helt skild och en central db struktur som synkar det nödvändiga mellan varandra.

[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?