Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Skalerbarhet i webapplikasjoner Kristoffer Dyrkorn BEKK Consulting.

Liknende presentasjoner


Presentasjon om: "Skalerbarhet i webapplikasjoner Kristoffer Dyrkorn BEKK Consulting."— Utskrift av presentasjonen:

1 Skalerbarhet i webapplikasjoner Kristoffer Dyrkorn BEKK Consulting

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

3 Sentrale begreper

4 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: http://www.wikipedia.org

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

6 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”

7 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

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

9 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

10  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

11 Forsinkelse versus prosesseringsevne Side 11

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

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

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

15 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? 53336318711941638496217 33716

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? 53336318711941638496217 33716

17 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 1733716 53336318711941638496217 5 min.

18 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

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

20 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-55d97640 1.(Innhold) ETag: e842a-3e53-55d97640 2.304 Not Modified KlientServer

21 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:00 2.304 Not Modified KlientServer

22 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å: http://www.mnot.net/cache_docs/ 1.GET /index.html 2.GET /index.html 1.(Innhold) Expires: 3600 2.- KlientServer

23 Arkitektur

24 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”

25 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

26 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

27 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

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

29 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 (http://en.wikipedia.org/wiki/Shared_nothing_architecture)

30 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

31 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: http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing

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

33 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

34 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å: –http://developer.yahoo.com/performance/ –Bruk FireFox og FireBug-pluginen YSlow

35 Praktisk eksempel: www.forskningsradet.no

36 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

37 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

38 Oppbygning av sider Side 38

39 Oppbygning av sider Side 39

40 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

41 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

42 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

43 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

44 Forsiden på forskningsradet.no – første gang Side 44 GET /no/Forsiden/1173185591033 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=1220887462603&ssbinary=true GET /servlet/Satellite?blobcol=urldata&blobheader=image%2Fjpeg&blobkey=id&blobtable=MungoBlobs&blobwhere=1221634235372&ssbinary=true GET /servlet/Satellite?blobcol=urldata&blobheader=image%2Fjpeg&blobkey=id&blobtable=MungoBlobs&blobwhere=1221634237131&ssbinary=true GET /servlet/Satellite?blobcol=urldata&blobheader=image%2Fjpeg&blobkey=id&blobtable=MungoBlobs&blobwhere=1221634216616&ssbinary=true GET /servlet/Satellite?blobcol=urldata&blobheader=image%2Fgif&blobkey=id&blobtable=MungoBlobs&blobwhere=1196353677290&ssbinary=true GET /servlet/Satellite?blobcol=urldata&blobheader=image%2Fgif&blobkey=id&blobtable=MungoBlobs&blobwhere=1196784534958&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

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

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

47 Spørsmål?

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


Laste ned ppt "Skalerbarhet i webapplikasjoner Kristoffer Dyrkorn BEKK Consulting."

Liknende presentasjoner


Annonser fra Google