1 / 48

Skalerbarhet i webapplikasjoner

Skalerbarhet i webapplikasjoner. Kristoffer Dyrkorn. BEKK Consulting. Agenda. Sentrale begreper Arkitektur og lagdeling av oppgaver Hvordan forespørsler behandles Hvordan oppnå god skalerbarhet? Praktisk eksempel. Sentrale begreper. Ytelse.

brigit
Télécharger la présentation

Skalerbarhet i webapplikasjoner

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Skalerbarhetiwebapplikasjoner Kristoffer Dyrkorn BEKK Consulting

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

  3. Sentrale begreper

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

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

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

  7. Forsinkelse Trykker på en lenke Forespørselen sendes Forespørselen mottas Svaret sendes Svaret mottas Svaret vises PC Nettverk Server Nettverk PC Tid fra en forespørsel påbegynnes til svaret begynner å komme

  8. Forsinkelser, ca-verdier 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 9 forespørsler Prosesseringsevne: 1 forespørsel pr sekund 9 sekunder Maksimalt antall forespørsler – per tidsenhet – som kan behandles rett etter hverandre

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

  11. Forsinkelse versus prosesseringsevne

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

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

  14. Caching – mellomlagring 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 Vil hente data med id = 16 Leser fra cache Finnes ikke, hentes fra original Kopien lagres i cachen Svaret returneres 16? 17 33 7 16 53 33 63 18 7 11 94 16 38 49 62 17 En cache inneholder en kopi av deler av det originale innholdet Utvalget baseres på hva som tidligere er lest Antagelse: Framtid = fortid

  16. Caching: Problemstillinger 17 33 7 16 53 33 63 18 7 11 94 16 38 49 62 17 • 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?

  17. Caching: Hvordan sikre gyldige data? 5 min. 17 33 7 16 53 33 63 18 7 11 94 16 38 49 62 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

  18. Caching: Hva tas bort når cachen er full? Antall leseoperasjoner som ble besvart av cachen Antall leseoperasjoner • Framgangsmåter for tømming (invalidering): • Random: Velg en tilfeldig • Round-Robin: Velg plass nr 1 første gang, deretter plass nr 2, osv • LeastRecently 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:

  19. Caching skjer et sted til Noenforslag? Hint: Detgårogså an å ikkesende en forespørsel

  20. Etag: En http header for caching Klient Server GET /index.html GET /index.html If-None-Match: e842a-3e53-55d97640 (Innhold) ETag: e842a-3e53-55d97640 2. 304 Not Modified • 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

  21. If-Modified-Since : En http header for caching Klient Server GET /index.html GET /index.html If-Modified-Since: 12:15 (Innhold) Last-Modified: 12:00 2. 304 Not Modified 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

  22. Expires: En http header for caching Klient Server GET /index.html GET /index.html (Innhold) Expires: 3600 2. - 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/

  23. Arkitektur

  24. Hva er arkitektur? • 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 • 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 Web-server • 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 Applikasjons-server • Tar i mot forespørsler fra applikasjonsserveren og sender svar tilbake til den Database-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

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

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

  29. Hvordan oppnå god skalerbarhet? • 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 Ikke lag distribuerte applikasjoner Noenforslag? Unngå å lagretilstandiflereserveresomgjørsamme type oppgave. Tilstandenmåsynkroniseres, ogdetervanskelig.

  31. De 8 andre lovene for distribuerte applikasjoner 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: Detteerironi) Kilde: http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing

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

  33. Billig og effektiv skalering • 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 • 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-pluginenYSlow

  35. Praktisk eksempel:www.forskningsradet.no

  36. Litt om Forskningsrådet • 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 Web-server • Setter sammen innholdselementer til ferdige sider • Cacher ferdige sider og leverer disse til webserveren Applikasjons-server • Leverer innholdselementer til applikasjonsserveren Database-server Leverer innhold til nettleseren Henter sider fra applikasjonsserveren og lagrer disse lokalt

  38. Oppbygning av sider

  39. Oppbygning av sider

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

  41. Optimalisering Web-server Web-server Remotecache Remotecache Applikasjons-server Database-server • Remotecache • 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

  42. Caching-metode Fragmenter som hentes fra database Cachede fragmenter Cachet side 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 Ansatt Ansatt Siden caches på ny

  43. Caching på remote server og på klient • 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 268 kb 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

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

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

  47. Spørsmål?

  48. Takk! Kristoffer Dyrkorn BEKK Consulting kristoffer ætt bekk dåttno

More Related