Skalerbarhet i webapplikasjoner Kristoffer Dyrkorn BEKK Consulting

Agenda Side 2  Sentrale begreper  Arkitektur og lagdeling av oppgaver  Hvordan forespørsler behandles  Hvordan oppnå god skalerbarhet?  Praktisk eksempel

Sentrale begreper

Ytelse Side 4 Depending on the context, good computer performance may involve one or more of the following: Short response time for a given piece of workresponse time High throughput (rate of processing work)throughput Low utilization of computing resource(s)computing resource High availability of the computing system or application High availability Fast (or highly compact) data compression and decompressiondata compression High bandwidth / short data transmission timebandwidthdata transmission Kilde:

Ytelse Side sekunder 1forespørsler per sekund ”Ved 1 forespørsel per sekund tar det 1.2 sekunder å få svar”

Skalerbarhet Side 6 a sekunder xforespørsler per sekund a * 1.5 x * 2 ”Dobles antall forespørsler, tar det 1.5 gang så lang tid å behandle dem”

Forsinkelse Side 7  Tid fra en forespørsel påbegynnes til svaret begynner å komme Trykker på en lenke Forespørselen sendes Forespørselen mottas Svaret sendes Svaret mottas PCNettverkServerNettverkPC Svaret vises

Forsinkelser, ca-verdier Side 8  RAM cache: 5 ns  RAM: 50 ns  Harddisk: 5 ms = ns  LAN: 10 ms = ns  WAN: 100ms = ns

Prosesseringsevne Side 9  Maksimalt antall forespørsler – per tidsenhet – som kan behandles rett etter hverandre 9 sekunder 9 forespørsler Prosesseringsevne: 1 forespørsel pr sekund

 Hva skjer ved 1.5 sekunders forsinkelse mellom hver forespørsel?  Viktig å unngå forsinkelser Forsinkelser ødelegger reell prosesseringsevne Side 10 9 sekunder 3 forespørsler Prosesseringsevne: 0.3 forespørsler pr sekund

Forsinkelse versus prosesseringsevne Side 11

Skalering – oppover Side 12  Øke systemets kapasitet ved å øke kapasiteten på enkelt-maskiner  Typisk CPU/RAM/Harddisk/Nettverkskort Server

Skalering – utover Side 13  Øke systemets kapasitet ved å legge til flere maskiner  Maskinene har samme rolle (gjør samme oppgaver) Server

Caching – mellomlagring Side 14 Har: En treg ressurs med stor kapasitet En rask ressurs med liten kapasitet Vil ha: En rask ressurs med stor kapasitet Hva kan gjøres?

Caching - mellomlagring Side 15  En cache inneholder en kopi av deler av det originale innholdet  Utvalget baseres på hva som tidligere er lest  Antagelse: Framtid = fortid Vil hente data med id = 16 Leser fra cache Finnes ikke, hentes fra original Kopien lagres i cachen Svaret returneres 16?

Caching: Problemstillinger Side 16  Utgangspunkt: –Ta vare på dataene – så lenge det er plass i cachen –Gjenbruk dataene – så lenge de er gyldige  Hva skal man gjøre når det ikke lengre er plass?  Hva skal man gjøre når de ikke lengre er gyldige?  Hvordan vet man om de er gyldige?

Caching: Hvordan sikre gyldige data? Side 17  Alle endringer skjer via cachen  Endringer skjer utenfor, men cachen oppdateres samtidig  Cache-elementer tømmes etter en viss tid –Tillater ugyldige data en kort periode min.

Caching: Hva tas bort når cachen er full? Side 18  Framgangsmåter for tømming (invalidering): –Random: Velg en tilfeldig –Round-Robin: Velg plass nr 1 første gang, deretter plass nr 2, osv –Least Recently Used: Den som har ligget ulest lengst, forsvinner –Most Recently Used: Den som har ligget ulest kortest, forsvinner –FIFO: First-In-First-Out –LIFO: Last-In-First-Out  Hva er best? –Ja. Velg metode ut fra lese- og skrivemønsteret –LRU gir ofte gode resultater –Hit rate: Antall leseoperasjoner som ble besvart av cachen Antall leseoperasjoner

Caching skjer et sted til Side 19  Noen forslag?  Hint: Det går også an å ikke sende en forespørsel

Etag: En http header for caching Side 20  Serveren regner ut en kode som er unik for hver side –Hvis siden endrer seg, vil koden endre seg  Nettleseren tar med koden i nye forespørsler mot samme side  Serveren sjekker koden –Siden sendes på ny kun hvis koden er forskjellig  Det kan være ressurskrevende å regne ut koden 1.GET /index.html 2.GET /index.html If-None-Match: e842a-3e53-55d (Innhold) ETag: e842a-3e53-55d Not Modified KlientServer

If-Modified-Since : En http header for caching Side 21  Serveren svarer med en angivelse av når innholdet sist ble endret  Nettleseren sender med tidspunktet  Har siden blitt endret i mellomtiden sendes den på nytt 1.GET /index.html 2.GET /index.html If-Modified-Since: 12:15 1.(Innhold) Last-Modified: 12: Not Modified KlientServer

Expires: En http header for caching Side 22  Serveren svarer med en angivelse av hvor lenge nettleseren kan lagre innholdet  Bruk Firefox og ”Live HTTP Headers” plugin  Se også: 1.GET /index.html 2.GET /index.html 1.(Innhold) Expires: KlientServer

Arkitektur

Hva er arkitektur? Side 24  Forslag?  Utgangspunkt –Et behov skal dekkes  Verktøy –Man har en rekke enkeltkomponenter som løser delbehov  Konstruksjon –En arkitektur organiserer enkeltkomponentene på en måte som gjør at behovet dekkes  En mulig beskrivelse: ”Samspillet mellom komponenter i et system som gjør at systemet dekker det behovet det skal”

Viktig prinsipp: En komponent gjør én oppgave Side 25  Ikke gjenta deg selv –Forenkler feilsøking –Forenkler caching –Forenkler endringer  Fordel ressurser (RAM, CPU, disk, båndbredde) riktig –Ulike komponenter har ulike ressursbehov  Ulike komponenter har ulik grad av skalerbarhet –Kost/nytte vil spille inn

Ansvarsfordeling i webapplikasjoner Side 26 Database- server Applikasjons- server Web-server  Tar i mot forespørsler fra nettleseren  Behandler noen forespørsler selv – og sender da data tilbake til nettleseren  Andre forespørsler sendes videre til applikasjonsserveren  Tar i mot forespørsler fra webserveren  Behandler noen forespørsler selv – og sender da data tilbake til webserveren  Andre forespørsler sendes videre til databaseserveren  Tar i mot forespørsler fra applikasjonsserveren og sender svar tilbake til den

Forespørsel og svar – eksempel 1 Side 27 Database- server Applikasjons- server Web-server GET index.html SELECT * from people [”Ola Nordmann”, 1234 Oslo] SELECT * from products [”Apple iPhone”, ”16 GB”] Ola: 16 GB

Forespørsel og svar – eksempel 2 Side 28 Database- server Applikasjons- server Web-server GET image.gif

Hvordan oppnå god skalerbarhet? Side 29  La responser besvares så tidlig som mulig –Sørg for korte dataveier  Bytt ut prosessering av data med lesing av ferdige data –Bruk caching  Balanser ressursbruken (CPU, RAM, båndbredde, disk) –Undersøk enkelt-komponentenes oppførsel og behov –Fjern flaskehalsene  Utnytt muligheter for parallellitet og distribusjon –Skaler utover, MEN unngå ressursdeling og -synkronisering –Bruk shared-nothing-prinsipper (

Første lov for distribuerte applikasjoner Side 30  Noen forslag?  Unngå å lagre tilstand i flere servere som gjør samme type oppgave. Tilstanden må synkroniseres, og det er vanskelig. Ikke lag distribuerte applikasjoner

De 8 andre lovene for distribuerte applikasjoner Side 31  The network is reliable  Latency is zero  Bandwidth is infinite  The network is secure  Topology doesn't change  There is one administrator  Transport cost is zero  The network is homogeneous  (Hint: Dette er ironi) Kilde:

Skalering utover kan være dyrt og vanskelig Side 32 Database- server Applikasjons- server Web-server  kr pr stk  Holder på sesjonen med nettleseren  Trenger ikke synkroniseres  kr pr stk  Holder på sesjonsdata, dvs data for påloggede brukere  Cacher og sesjonsdata må synkroniseres  kr per stk (maskinvare og programvare)  Holder på applikasjonsdata for alle brukere  Data må synkroniseres

Billig og effektiv skalering Side 33  Skaler oppover først, og siden utover –Distribusjon er vanskelig  Plasser belastningen så høyt opp i arkitekturen som mulig –Unngå at forsinkelser ødelegger prosesseringsevnen –Unngå synkronisering og kompleksitet –Unngå store utgifter  Utnytt alle muligheter –I korte perioder trenger kanskje ikke alle komponenter å være oppdaterte –Se på hvilke krav man har og hvilke friheter man kan ta seg  Bruk anerkjent og utbredt programvare –Mindre sjanse for feil

Optimalisering på klientsiden Side 34  Se på hvilke ressurser som lastes ned  Må disse lastes ned hver gang?  Hvor lenge kan man lagre disse selv?  Bruk http headere til å hindre nye forespørsler  Se også: – –Bruk FireFox og FireBug-pluginen YSlow

Praktisk eksempel:

Litt om Forskningsrådet Side 36  Forskningsrådet fordeler 5.4 mrd NOK hvert år  Fremmer forskning og innovasjon, er møteplass og politisk rådgiver  6 søknadsfrister i året  Søknader tilgjengeliggjøres via web  Viktigste krav til skalering er –Å håndtere store trafikkmengder ved søknadsfrister –Å håndtere publisering ved store trafikkmengder

Ansvarsfordeling Side 37 Database- server Applikasjons- server Web-server  Leverer innhold til nettleseren  Henter sider fra applikasjonsserveren og lagrer disse lokalt  Setter sammen innholdselementer til ferdige sider  Cacher ferdige sider og leverer disse til webserveren  Leverer innholdselementer til applikasjonsserveren

Oppbygning av sider Side 38

Oppbygning av sider Side 39

Fysisk arkitektur følger ansvarsfordelingen Side 40 Database- server Applikasjons- server Web-server LB Web-server Database- server Applikasjons- server Web-server Redigering av innhold Visning av innhold Publisering

Optimalisering Side 41  Remote cache –Ferdige sider lagres i RAM –Bilder lagres på disk  Fragment cache –Sideelementer lagres i RAM  Query cache –Resultater fra database lagres på disk  Database-cache –Innebygd i databasen Database- server Applikasjons- server Web-server Remote cache

Caching-metode Side 42 Ansatt Fragmenter som hentes fra database Cachede fragmenter Cachet side Ansatt Systemet vet hvilke sider som viser ansatt- informasjon Sidecachen tømmes for de sidene Ett av elementene på en side inneholder ansatt- informasjon, dette må bygges opp på nytt Elementet med ansatt- informasjon hentes på nytt De andre elementene gjenbrukes Siden caches på ny

Caching på remote server og på klient Side 43  Prinsipp: –Lagre så mye som mulig i RAM –Lagre i RAM kun det som må hentes for hver forespørsel –Lagre alt annet på disk  Løsning: –HTML-fragmenter og ferdige sider lagres i RAM (500 MB cache) –Redaksjonelle bilder caches til disk –Statiske filer (CSS, GIF, JS) lagres til disk –Browsercaching brukes for alle statiske filer + for redaksjonelle bilder –Varighet: 1 time

Forsiden på forskningsradet.no – første gang Side 44 GET /no/Forsiden/ GET /forskningsradet/js/nfr.js GET /forskningsradet/css/forskningsradetComplete.css GET /forskningsradet/css/print.css GET /forskningsradet/gfx/txt_frntpg_flytte.gif GET /forskningsradet/gfx/txt_frntpg_publ.gif GET /forskningsradet/gfx/txt_frntpg_prgrm.gif GET /forskningsradet/gfx/txt_frntpg_prosj.gif GET /forskningsradet/gfx/logo.gif GET /servlet/Satellite?blobcol=urldata&blobheader=image%2Fjpeg&blobkey=id&blobtable=MungoBlobs&blobwhere= &ssbinary=true GET /servlet/Satellite?blobcol=urldata&blobheader=image%2Fjpeg&blobkey=id&blobtable=MungoBlobs&blobwhere= &ssbinary=true GET /servlet/Satellite?blobcol=urldata&blobheader=image%2Fjpeg&blobkey=id&blobtable=MungoBlobs&blobwhere= &ssbinary=true GET /servlet/Satellite?blobcol=urldata&blobheader=image%2Fjpeg&blobkey=id&blobtable=MungoBlobs&blobwhere= &ssbinary=true GET /servlet/Satellite?blobcol=urldata&blobheader=image%2Fgif&blobkey=id&blobtable=MungoBlobs&blobwhere= &ssbinary=true GET /servlet/Satellite?blobcol=urldata&blobheader=image%2Fgif&blobkey=id&blobtable=MungoBlobs&blobwhere= &ssbinary=true GET /forskningsradet/gfx/background.gif GET /forskningsradet/gfx/page_header_shadow.gif GET /forskningsradet/gfx/img_frntpg.jpg GET /forskningsradet/gfx/gray_shadow.gif GET /forskningsradet/gfx/bullet.gif GET /forskningsradet/gfx/footer.gif 268 kb

Forsiden på forskningsradet.no – en gang til Side 45 GET /no/Forsiden/ kb

Oppsummert Side 46  Legg belastningen høyt i arkitekturlagene –Eller på nettleseren  Behandle forespørsler lokalt  Unngå generering av data

Spørsmål?

Side 48 Kristoffer Dyrkorn BEKK Consulting kristoffer ætt bekk dått no Takk!