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

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