[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 dvs den hämtar info från db'n varje sekund. Jag tänker lite långsökt och optimistiskt just nu men säg att man har 10M användare till appen som kommer vara gratis och säg att 1M använder appen samtidigt, det innebär att vi kommer att ha en väldans massa requests till databasen som är en mySQL databas, det jag undrar är hur kraftig server skall man ha för att kunna hantera detta? klarar mySQL detta? någon med någon erfarenhet av mass trafik, vad bör man tänka på? Är det lastbalansering mellan olika servrar som gäller eller ska man preppa en server med massor med RAM minne?

Uppskattar all hjälp man kan få kring detta.

[coredev]

Tyvärr är det tråkiga svaret: "det beror på".

Att alla användare skall pinga databasen varje sekund kommer ge dig huvudvärk om (när?) din app blir populär. Det kan bli mycket svårt att skala upp. Har du några möjligheter att rent arkitektursikt att lösa det på annat sätt?

Har du funderat på VPS / en molnapplikation, det skulle kunna ge dig större möjligheter att skala upp om det smäller till.

[Gimbo]

Har tyvärr inte så stenkoll på serverside tekniken, vad skulle en VPS/moln app innebära? Det är just därför jag är lite orolig säg att den växer och växar kraftigt så kan man med en server trycka in mer RAM minne men vet inte om det skulle räcka?

Skulle va snällt om du kunde utveckla detta med VPS / molnapp.

[Digitum]

Det finns mycket teori bakom det hela men räkna med att ett paket, hur litet det än är, kommer att belasta din lina med minst 64 bytes, eller ca 0,5kbit. Så, håller du ner paketstorleken till detta vid ditt "pingande" så belastas dina servrar med 500 Mbit/sek. Sen är det ju klart att det även innebär en miljon databasaccesser per sekund.

En normal server klarar kanske ett par hundra anrop per sekund i genomsnitt. Sen är det klart, att om varje förfrågan måste ut på hårddisken och samla lite data så klarar du som mest kanske 60 förfrågningar per sekund om du har en 7200rpm hårddisk, men det är högst teoretiskt.

En vanlig databas är nog inte vad du skall ha ...

[Gimbo]

Oj så pass, vad är det då man skall ha om inte en vanlig db?
Jag funderade på en dedikerad server med 16gb i ram minne och ett par Tbit i hårddisk och db'n är en mySQL, jag borde alltså räkna bort detta helt?

[Clarence]

En miljon pings mot databasen varje sekund? Det låter som om du har en klassisk subscriber-modell du vill tillämpa. Isåfall bör du istället lösa det med en applikation som hanterar anslutningar och hämtar kollektivt från databas/cache/nosql för sina anslutningar. Annars skapar du dig utmaningar du inte alls borde ha.

Det för tillfället mest populära valet för sådana typer av applikationer är nog node.js. Förut var det mer egenknackad java.

En hyfsad mysql-burk klarar ett gäng tusen enklare frågor i sekunden utan problem. Att den bara skulle klara 60 skrivningar på en 7200 disk är kanske inte heller så bra slutsats. Förutsatt att du inte flushar till disk vid varje skrivning ska du lätt kunna komma upp i ett par hundra om det inte är för mycket data att skriva och mer sekventiellt än slumpmässigt.

Behöver du nå en miljon reads per sekund bör du nog titta på färdiga klusterlösningar. Vill du inte släppa mysql finns det mysql cluster och percona cluster. Annars finns det gott om nosql-lösningar med kluster-arkitektur. Men då du inte sagt något alls om din data är det svårt att försöka rekommendera något.

Men som sagt, rent arkitekturellt misstänker jag (som coredev redan nosade på) att du är helt fel ute.

[coredev]

Nu vet jag ju inte vad det gäller för app, men här kommer några generella tankar.
- När det gäller arkitekturen på din programvara så behöver inte allt alltid ske i realtid, ibland räcker det med att det verkar ske i realtid.
- En sekund är en väldigt kort tid för en människa, vi hinner inte ens reagera på den tiden. Är du säker på att var femte sekund inte räcker? Redan där har du minskat belastningen med 1/5.
- Måste man vara uppkopplad i alla lägen i appen, finns det tillfällen då man inte behöver polla servern lika ofta / öht? Genom att stänga av pollningen när t.ex. en dialogruta öppnas så kan du spara mycket resurser.
- Vissa data ändras mer sällan, memcached kan vara din vän i vissa sådana fall.

[Gimbo]

Lite mer info om själva appen, så att ni får en bättre bild av det hela...

Appen är ett ord spel, där man lägger ord i brickor och man möter en motspelare, brickläggandet sker i realtid, dvs man lägger en bokstav och den visas hos motspelaren direkt, så det är ett konstant pingande. Motspelaren lägger en bricka, den uppdaterar DBn och därefter så sitter motspelaren och lyssnar på db'n och hämtar info't därifrån. Det är inga stora datamängder som hanteras utan det är mer att dte är uppslag mot DBn konstant. Sedan finns det ett chatt där man sitter och lyssnar på DBn konstant, detta går ju att lösa med en uppdatera knapp men det känns lite B-aktigt. Chatten fungerar på samma sätt, man skriver och hämtar infot från en DB tabell.

Skulle en klustrad mySQL lösning fungera i detta syfte?

[Clarence]

Att försöka lösa det problemet genom att hämta från databasen hela tiden är helt fel väg att gå om du vill få någon som helst prestanda i systemet.

För varje "action" (lägga bricka, skriva meddelande) behöver du en skrivning till databasen, men det finns ingen anledning för varje användare att fråga databasen efter ny data precis hela tiden var och en för sig.

Istället skulle du kunna ha en server-applikation som varje klient ansluter till. Varje anslutning premenurerar på olika kanaler. T ex wordgame-2323 eller chatt-2342 (om de nu är skilda). För varje skrivning så skickas även datan till denna server-applikation som skickar meddelandet till alla subscribers över anslutningen som redan är öppen. Det är endast när en helt ny anslutning, eller en disconnect sker, som det finns anledning att hämta allt från databasen. Eventuellt kan också denna server-applikation skicka kompletta spel-informationen för ordspelet varje gång en handling sker - med vettig serialiserad datastruktur rör det sig nog inte om mer än någon eller några kb?

Men vill du absolut inte förändra något i ditt tänk kan du mycket väl lösa det genom mycket sämre prestanda och ökade skalbarhetsproblem genom en anpassad klusterdatabas.

[patrikweb]

En server är inte skalbart i grunden, även om det säkert funkar till en viss nivå.

Jag föredrar mer kraftiga VPS paket, eller flera VPS paket utspridda på flera server.

Eller i vissa fall flera fysiska servrar, dock flera fysiska servrar blir en viss begränsning och osmidighet för en kund att hantera än VPS.

Fördelar med virtuell miljö är att man kan växa i steg, du kan bygga ett MySQL kluster som du lägger till mer noder efter belastning.

Efter du har antagligen väldigt mycket mer read en write, och ett kluster för hantera endast stor mängd read är inte så komplicerat. Se till att ha mycket minne så du har hela DB i minnet.