Skalerbart system

kongen

kongen

kongemedlem
Hva må man tenke på når man skal takle høye besøkstall?

Hva er det som gjør at Altinn kræsjer hver gang folk skal levere selvangivelsen april/mai?
 
xdex

xdex

Medlem
Hvorfor altinn kræsjer hver gang, er vel en kombinasjon av flere ting. Skal du takle høyt antall besøkende f.eks. vil jeg i hvert fall bruke en cloud vps løsning, og skalere etter behov, men her også, er det relativt.

Det er også viktig at du har ett system som er optimalisert, som fungerer og skalarer greit om du f.eks. ønsker å utvikle videre. Er det f.eks. enkelt og skalere joomla? hvilken begrensning har dette? kan Wordpress være ett bedre alternativ? Ville f.eks. ruby on rails taklet dette langt bedre, ved å lage noe fra bunnen av selv?

Snakker vi om 1000 besøkende som stadig vekk er aktiv på siden, eller snakker vi om 60.000 som stadig vekk er aktiv? Slik informasjon er jo gull verdt for ett best mulig svar.
 
kongen

kongen

kongemedlem
Er det noen cloudløsninger som har servere i Norge? Rackspace, Amazon og alle disse har vel serverene sine plassert "overalt" unntatt Norge, eller tar jeg feil her? Er man dømt til å bruke dedikerte servere for løsninger rettet mot nordmenn?

Er det noen begrensninger på en mysql database / server? Har hørt at disse begynner å slite ved ca 1 mill insert/update om dagen.
 
hansson

hansson

Langveisfarende
Noen ideer for å unngå kapasitetsproblemer:

Vurdér å kutte Apache og bruke NodeJS. En node-server er lynrask og kan kjøre nærmest ubegrensa antall tilkoblinger asynkront, altså uten trafikkork. http://en.wikipedia.org/wiki/Node.js

Lager du selve applikasjonen stateless (lagrer ikke sessions, bruker web tokens på ulike måter) vil du enklere kunne spre belastningen på så mange servere du vil (load balancing) og fyre opp nye cloud-servere ved økt behov.

Kanskje du kan bli inspirert av Facebooks asynkrone MySQL-klient som er åpen kildekode, og gjør de i stand til å håndtere verdens største MySQL-installasjon: http://www.percona.com/live/mysql-c...chronous-mysql-how-facebook-queries-databases.
 
adeneo

adeneo

Medlem
hansson skrev:
Vurdér å kutte Apache og bruke NodeJS. En node-server er lynrask og kan kjøre nærmest ubegrensa antall tilkoblinger asynkront, altså uten trafikkork.
Klikk for å utvide...

En sannhet med visse modifikasjoner.

Node er lynrask til å håndtere tilkoblinger og genialt til skalerbare løsninger med mye trafikk, men fordi det fremdeles er JavaScript så bruker Node bare en tråd, noe som gjør Node fullstendig uegnet for løsninger som krever litt prosessorkapasitet ettersom alle tilkoblingene deler en tråd på prosessoren.

Dersom man ikke vet hva man driver med, er det ikke noe problem å skrive kode i Node som krasjer totalt ved et par tusen tilkoblinger fordi det ikke er nok prosessorkraft tilgjengelig.
Node er snill på minne, som er det store problemet i mange andre språk som bruker tradisjonell threading, men har problemer med ting som krever mer av CPU'en.

Et annet problem med single threading er at dersom det krasjer for en bruker, så krasjer det for alle, det finnes ingen andre tråder å ta av.

Nå i dag har Forever løst en del av problemet med krasj, og cluster modulen gjør at man bruke flere tråder, men det er fortsatt "eksperimentelt".

Node er altså helt topp dersom man bruker det til de rette tingene, og helt elendig til mange ting som for eksempel PHP eller Ruby klarer helt fint.
Samtidig er det mye lettere å rote seg bort i Node enn i for eksempel PHP, en del middleware som sails, express o.l. gjør ting litt enklere, men før man begynner med Node så bør man uansett ha forstått closures, scope, prototyping, asynkron kode og promises, og sikkert en del andre ting.
 
H

Hashead

Member
hansson skrev:
Noen ideer for å unngå kapasitetsproblemer:

Vurdér å kutte Apache og bruke NodeJS. En node-server er lynrask og kan kjøre nærmest ubegrensa antall tilkoblinger asynkront, altså uten trafikkork. http://en.wikipedia.org/wiki/Node.js

Lager du selve applikasjonen stateless (lagrer ikke sessions, bruker web tokens på ulike måter) vil du enklere kunne spre belastningen på så mange servere du vil (load balancing) og fyre opp nye cloud-servere ved økt behov.

Kanskje du kan bli inspirert av Facebooks asynkrone MySQL-klient som er åpen kildekode, og gjør de i stand til å håndtere verdens største MySQL-installasjon: http://www.percona.com/live/mysql-c...chronous-mysql-how-facebook-queries-databases.
Klikk for å utvide...
Selv om node kan brukes som en webserver er det ikke noen god ide å bygge en vanlig web-applikasjon i Node for å oppnå bedre ytelse. Den er anveldelig til veldig mye, men det er ikke en erstatter for niginx, apache eller lighttpd. Webserveren er så og si aldri flaskehalsen heller. Det vil bare skape flere problemer enn det løser.

Hvis mesteparten av trafikken din er anonym kan du bare legge Varnish foran og så er du på lang vei sikra.
Hvis ikke så blir det verre. Nøkkelen til skalering er å bygge med distibuerbare teknologier, altså ting som er designet for å kunne kjøre på flere maskiner samtidig, kjent som horisontal skalering.

Webservere er distribuerbare, memcached er distribuerbart, men de fleste sql databasene er ikke det, og byr dermed på mest hodebry av alle komponentene in stacken. Du kan kjøre master-master repliklering, men da bør du være veldig kyndig med databasen du bruker, og du vil sansynligvis ende opp med å måtte route spørringer i appliksjonen din. Uten at jeg kan si sikkert hvorfor altinn kræsjet, så er det nærliggende å tro at det var noe slikt som skjedde. Et datalager som ikke skalerte effektivt.

Så hvis du vet, eller har svært god grunn til å tro at du vil få en såpass stor mengde trafikk at en enkelt databaseserver ikke vil holde, typisk flere tusen aktive innloggede brukere, så kan du se på alternative databaseteknologier. Hvis du ikke er helt sikker, så bare bruk "vanlige" databaser, og ta sorgen med migrering hvis og når du må. Da har du forhåpentligvis råd til hjelp også.

Hvis du alikevel velger å ta sorgen nå og vil bygge noe helt distribuerbart, så er MonogDB lett å skalere og jobbe med hvis du føler deg trygg med å jobbe i NoSQL verdenen. Et annet alternativ er NuoDB, som skal være en distribuerbar sql database. Jeg titta på denne i fjor, men da var den i min mening ikke klar til produksjon.

Andre tips er bruk caching(!) og memcached, profiler applikasjonen din for å finne flaskehalser, og kjør alltid databaser på ssd disker. Jo raskere serveren kan behandle en request, desto flere klarer den å behandle.

Lykke til!
 
Du må logge inn eller registrere deg for å svare her.
Topp