Hva gjør en applikasjon skalerbar?

Det er to retninger for skalerbarhet:

• vertikal (aka skalering opp): raskere CPU, mer RAM, mer diskplass;
• horisontal (aka skalering ut): flere kjerner i CPU, flere CPUer, flere servere ;

For det første må du bare passe på at du ikke har noen vilkårlige begrensninger. Disse enten på grunn av for små heltallstørrelser eller strukturer med fast / begrenset lengde. Disse strukturene kan være relatert til underliggende operativsystem. For eksempel hvis du prøver å skalere opp ved å bruke flere tråder eller prosesser, vil du på et tidspunkt nå OS-grensene. Derfor gjør servere som bygger for høy skalerbarhet for øyeblikket samtidig basert på asynkrone hendelser. Dette problemet er beskrevet i berømte C10K dokument .

Den andre er vanskeligere. Det krever programmering med to ting i tankene: data blir behandlet parallelt, og data kan være fysisk distribuert. Kommunikasjonen mellom nodene skal være begrenset. I praksis betyr det vanligvis å ofre noen deler av ACID (det er bevist at du ikke kan ha full ACID og evne til å skalere ut samtidig). Den mest kjente løsningen for data lagring i dette paradigmet er NoSQL -løsninger. De spenner fra veldig enkle nøkkelverdilagre, til systemer RDBMS-lignende, bare fratatt evnen til å gjøre sammenføyninger. div id = «73fab16cf2»>

Skalerbarhet måles i form av gjennomstrømning basert på noen variabler. For eksempel antall forespørsler / sekund med X brukere. Den enkleste måten å beskrive skalerbarhet på er:

Et mål på effektivitet når belastningen øker.

Det første du må forstå når du designer for skalerbarhet, er hvilken måling som er viktigst for applikasjonen din. Det er flere måter å måle effektivitet som er en nøkkelkomponent i skalerbarhet:

• Samtidige forespørsler per sekund
• Gjennomsnittlig responstid per forespørsel
• Antall poster behandlet per sekund / minutt

Det er flere effektivitetsmålinger som kan brukes, men disse er vanlige for nettbaserte systemer eller batchbehandlingssystemer.

Det neste aspektet av skalerbarhet er å måle hva som skjer med effektiviteten din når belastningen økes. Vanlige måter å øke belastningen på er:

• Flere brukere som treffer serveren (dvs. mer webtrafikk)
• Flere data i databasen (dvs. spørsmål tar lengre tid, eller behandling tar lenger)
• Harddiskfeil i RAID (lagringsytelse / pålitelighet påvirkes)
• Nettverksmetning

Målet for et skalerbart program er for å opprettholde eller forbedre effektiviteten når vi takler lasteproblemet. Kort sagt, hvis responstiden tar for lang tid, kan vi legge til en annen server for å fordele belastningen jevnt? Denne tilnærmingen reduserer mengden arbeid for en server å gjøre, og holder serverne opererer i det «søte stedet» for effektivitet.

Du må applikere din egen applikasjon for å skalere. Det betyr at du må være forsiktig med øktdata, dirigere forespørsler til riktig server, redusere flaskehalser som begrenser muligheten for applikasjonen til å skalere.

Du vil i utgangspunktet unngå ytelsesflaskehalser når du øker antall brukere, og / eller behandler et større datasett , og / eller tilby grensesnittet på flere språk osv.

Du ser i utgangspunktet på databaseskjemaet ditt, algoritmene og programvareutviklingsprosessen og prøver å forutsi fremtidige problemer. Du vil også sette opp ytelsesovervåking for å identifisere problemer når de begynner å bygge opp.

Jeg plukket opp disse tipsene når jeg leste Bygg skalerbare nettsteder (lenke til amazon).

Håper dette hjelper!

Den eneste måten applikasjoner kan være virkelig skalerbar, er ved ikke å ha noen begrensninger som ikke kan overholdes (eller bare veldig dyrt).

Et typisk eksempel er hva som skjer når du går tom for tilgjengelige CPU-sykluser? Hvis programmet ditt har flere trinn, kan du kjøre på en boks med flere kjerner, men hva skjer når du ikke kan kjøpe en større boks lenger? Søknaden din kan ganske enkelt ikke vokse lenger, og er derfor ikke skalerbar.

Enhver virkelig skalerbar applikasjon må kunne spre seg over flere datamaskiner på en gjennomsiktig måte og gjøre det uten merkbare støt. DET er ikke lett, og det er en av grunnene til at Google har vært så vellykket.

Det er unike problemer som kommer med støtte for store skalerte applikasjoner. Stillingen søker etter søkere som har jobbet i dette miljøet og måtte løse slike problemer.

Fra et høyt nivå blir applikasjoner gjort skalerbare ved å stadig stille spørsmålet hva som ville skje hvis denne koden ble bedt om å kjøres tusenvis av ganger i en veldig liten periode. Dette betyr å administrere minnefotavtrykkene dine , bruker caching av totaler og data, bruker datakilder som er skalerbare selv osv.

Hvis du var bygge en søkefunksjon som presterte bra når den har 100 rader i DB for å søke og 10 brukere som bruker den om gangen. Hvor bra ville den prestert når 100 brukere brukte den samtidig og det er 100K rader å slå opp.

Hvis den utfører det samme uansett hva så er det veldig bra. det hvis det utfører proporsjonalt med mengden brukere / data (som betyr 10 ganger mer data == 10 ganger lenger å behandle) det er bra. Hvis det utfører mye senk jo flere data den har (10x modusdata == 10x ^ 10 lenger å behandle), så skaleres den ikke bra.

Eksemplene mine skal virkelig vises i Big O-notasjon, men jeg cu vet ikke det godt nok å skrive eksemplene i Big O.

Du kan simulere mer data ved å dumpe dummy-data i DB-en, og det finnes verktøy for å simulere flere brukere som Apache AB. / p>