Laste ned presentasjonen
Presentasjon lastes. Vennligst vent
PublisertIngebjørg Dahl Endret for 9 år siden
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!
Liknende presentasjoner
© 2024 SlidePlayer.no Inc.
All rights reserved.