Supercharge Website Performance med AWS S3 og CloudFront

Vi lever i en verden der folk i stigende grad forventer mer og raskere hastigheter. I brøkdeler av et sekund kan nettstedet ditt miste verdifulle besøkende og i sin tur penger. Selv om de fleste tror CDN er for de "store hundene", er de faktisk super billige og utrolig enkle å bruke i disse dager.

I denne veiledningen vil jeg vise deg hvordan du konfigurerer og bruker Amazons Web Services S3 og CloudFront for å redusere nettstedets lastetid, samt vise resultatforskjellene.

Hva er en CDN?

En CDN er et Content Delivery (eller distribusjons) -nettverk. Det er et nettverk av datamaskiner med hvert system plassert på forskjellige punkter med samme data på hver. Når noen får tilgang til nettverket, kan de få tilgang til filen på systemet nærmest dem eller den som har mindre strømbelastning. Dette resulterer i bedre lavere ventetid og filnedlastingstid. For å lære mer om CDN-er, se "Innholdsleveringsnettverk" på Wikipedia.

I eksempelbilaget ovenfor får besøkende tilgang til den nærmeste serveren som gir best mulig ytelse. Nettverket av servere ville være CDN. En vanlig webverten ville ha en sentral server der alle de besøkende måtte få tilgang. Den ene serveren kan bare være lokalisert i USA eller kanskje Europa, og vil resultere i lengre latens og belastetider for besøkende lengre unna.

Å bruke mer enn én server, selv på bare ett kontinent, vil gjøre en forskjell i ytelsen.

Hvorfor og beviset

Jeg har hatt ganske mange folk spør meg om hvorfor en CDN er viktig, selv for mindre nettsteder, og hvorfor de burde plage å betale for enda en webtjeneste. Det enkle svaret er, jo raskere-jo bedre. Og hvorfor ikke tilby kundene dine (besøkende) det beste du kan?

Jo mindre nettsiden, jo mindre av en innvirkning en CDN vil gjøre. Selv om dine besøkende oversetter til penger for deg, hjelper hver liten bit.

  • I 2006 viste Googles tester at økt lastetid med 0,5 sekunder resulterte i en 20% nedgang i trafikken.
  • I 2007 viste Amazonas tester at for hver 100ms økning i belastetid vil salget redusere 1%.
  • I år (2009) viste Akamai (en CDN-leder) i en undersøkelse at 2 sekunder er den nye terskelen for eCommerce websiden responstider.

Det er billig. Det er lett. Og det kan oversette til mer penger når det gjelder kunder og sparer på dine vanlige webvertenutgifter.

Amazon Web Services (AWS)

Amazon tilbyr en hel rekke fantastiske webtjenester. Vi bruker Amazons Simple Storage Service (S3) og CloudFront. S3 er en datalagringsløsning i skyen som kan knyttes til CloudFront, Amazonas CDN.

Hvis du leter etter en litt enklere, alt-i-ett-løsning, er Rackspace Cloud Files et annet godt alternativ. De har samarbeidet med Limelight Network's CDN, som har litt bedre ytelse enn Amazonas CDN. Imidlertid har tjenesten deres noen ulemper som du ikke finner med Amazon. Jeg kommer ikke inn i alle disse, men en av de større for meg var mangelen på tilpasset CNAME-støtte som tilsynelatende kommer på et tidspunkt i fremtiden. Med CNAME-støtte kan du sette opp et tilpasset underdomene for å få tilgang til filene dine, for eksempel "cdn.yourdomain.com".

For å se de siste ytelsesjämförelsene, besøk http://www.cloudclimate.com/cdns/

Priser

Her er Amazonas S3-priser for USA. For andre områder, klikk på bildet for å se full prising.

Her er Amazons CloudFront-priser for USA. For andre områder, klikk på bildet for å se full prising.

Bruk Amazons månedlige kalkulator for å få en bedre ide om sluttregningen. Forrige måned var min totale regning mindre enn $ 5, med størstedelen av det som oppstod fra 20 GB + av datalagring. Som du ser, er det veldig, veldig billig, spesielt når du tar hensyn til ytelses- og fleksibilitetsfordelene.

Oppsett S3 og CloudFront

For å komme i gang må vi registrere seg for Amazonas S3 og CloudFront-tjenester. Hvis du allerede har en konto hos Amazon, trenger du bare å logge inn og fullføre registreringen. Hvis ikke, må du opprette en konto, deretter fortsett å registrere deg for S3 og CloudFront. Registreringen er ganske enkelt å legge til tjenesten på kontoen din. Det er ikke noe komplisert involvert.

Klikk på hvert bilde for å gå til tjenestens informasjon og registreringsside.

Når du har registrert deg, får du en Access Key ID og Secret Access Key som du finner under "Din konto"> "Sikkerhetserklæring". Dette er i utgangspunktet ditt brukernavn og passord for å få tilgang til S3.

Oppsett S3 Bucket For Files

Først må vi lage en bøtte for å lagre alle våre filer. For mer informasjon om "bøtter" les "Amazon S3 Buckets Described in Plain English".

For å gjøre dette, logger vi først inn på vår S3-konto ved hjelp av Access Key ID og Secret Access Key med et program som Transmit (OS X), som er det jeg skal bruke. For å se flere apper eller nettlesertilskudd for å få tilgang til S3, se "Amazon S3 Simple Storage Service - Alt du ønsket å vite".

Når du er logget inn, lager vi en bøtte for å sette inn våre filer. Jeg har kalt min "files.jremick.com". Skuffer må ha unike navn, må være mellom 3 og 63 tegn og kan inneholde bokstaver, tall og bindestreker (men kan ikke ende med et dash).

Unikt betyr de unike på AWS-nettverket. Så det er en god ide å bruke noe som en nettadresse eller noe lignende.

Filene vi legger inn i denne bøtte kan nå nås på "files.jremick.com.s3.amazonaws.com". Denne nettadressen er imidlertid ganske lang, og vi kan raskt sette opp en kortere. Vi oppretter en ny CNAME-oppføring på webverten vår for å gjøre dette.

Oppsett Tilpasset S3-underdomene

For å forkorte standardwebadressen oppretter vi en CNAME-oppføring som jeg har gjort nedenfor (dette er på webverten). Jeg har valgt "filer" som underdomenet mitt, men du kan bruke det du vil.

Nå kan vi få tilgang til disse bøttefilene på "files.jremick.com". Mye bedre! Deretter laster du opp filene du vil ha i "files.jremick.com" bøtte.

Når filene dine er lastet opp, vil du angi ACL (Access Control List) slik at alle kan lese filene (hvis du vil ha dem offentlige). I Overfør du bare høyreklikk, velg få info, under tillatelser satt "Les" til "World" og klikk "Apply to enclosed items ...". Dette vil gi alle filene i denne bøtte lese tilgang til verden.

Som standard vil filer som lastes opp til S3-kontoen din, bare tillate lese og skrive tilgang til eieren. Så hvis du laster opp nye filer senere, må du gå gjennom disse trinnene på nytt eller bruke forskjellige tillatelser for bare de filene.

Opprett CloudFiles Distribution

Nå som vi har oppsett S3, opprettet en kortere URL og lastet opp våre filer, vil vi gjøre disse filene tilgjengelige gjennom CloudFront for å få super lav latenstid for å redusere belastningstiden. For å gjøre dette må vi opprette en CloudFront-distribusjon.

Logg deg på din AWS-konto og naviger til Amazon CloudFront-styringskonsollen (under rullegardinmenyen "Din konto"). Klikk deretter på "Opprett distribusjon" -knappen.

Vi velger opprinnelsesbøtte (bøtte vi opprettet tidligere), slå på logging hvis du vil, angi en CNAME og kommentarer og endelig enten aktivere eller deaktivere distribusjonen. Du trenger ikke å skrive inn en CNAME eller kommentarer, men vi vil sette opp en kortere URL senere som vi gjorde for S3. Jeg vil gjerne bruke "cdn.jremick.com" så det er det jeg legger inn her.

Som du kan se, er standard nettadressen ganske stygg. Det er ikke noe du vil prøve å huske. Så la oss nå sette opp en CNAME for den ganske, korte nettadressen.

Oppsett egendefinert CloudFiles-underdomene

For å sette opp det egendefinerte CloudFiles-underdomenet, går vi gjennom samme prosess som vi gjorde for S3.

Nå kan vi få tilgang til filer gjennom CloudFront ved å bruke "cdn.jremick.com".

Slik fungerer det

Når noen får tilgang til en fil gjennom S3-skuffen, virker den som en vanlig filvert. Når noen får tilgang til en fil gjennom CloudFiles, vil den imidlertid kreve filen fra S3-bucket (opprinnelsen) og cache den på CDN-serveren nærmest den opprinnelige forespørselen for alle påfølgende forespørsler. Det er litt mer komplisert enn det, men det er den generelle ideen.

Tenk på en CDN som et smart nettverk som kan bestemme raskest mulig rute for forespørsel. Et annet eksempel ville være hvis serveren nærmest er slått ned med trafikk, kan det være raskere å få filen fra en server litt lenger unna, men med mindre trafikk. Så CloudFront vil levere den forespurte filen fra stedet i stedet.

Caching Problemer

Når en fil er lagret i CloudFront-nettverksservere, blir den ikke erstattet før den utløper og blir automatisk fjernet (etter 24 timers inaktivitet som standard). Dette kan være en stor smerte hvis du prøver å skyve oppdateringer ut umiddelbart. For å komme seg rundt dette må du redigere filene dine. For eksempel kan "my-stylesheet.css" være "my-stylesheet-v1.0.css". Så når du lager en oppdatering som trenger å gå ut umiddelbart, vil du endre navnet til "my-stylesheet-v1.1.css" eller noe lignende.

Ytelsestesting

Vårt innhold lastes opp til vår S3-bøtte, vår CloudFront-distribusjon distribueres og våre tilpassede underdomener er konfigurert for enkel tilgang. Det er på tide å sette det på prøve for å se hva slags ytelsesfordeler vi kan forvente.

Jeg har oppsett 44 eksempelbilder som varierer i størrelse fra ca 2KB opp til 45KB. Du kan tenke at dette er flere bilder enn de fleste nettsteder vil laste på en enkelt side. Det kan være sant, men det er mange nettsteder som porteføljer, e-handel nettsteder, blogger, etc. som laster like mange og muligens flere bilder.

Selv om jeg bare bruker bilder for dette eksempelet, er det viktig at filstørrelsen og mengden for sammenligningen er. Dagens nettsteder laster inn flere javascript, CSS, HTML og bildefiler på hver side. 44 filforespørsler er sannsynligvis færre enn de fleste nettsteder faktisk gjør, slik at en CDN kan få enda større innvirkning på nettstedet ditt enn vi ser i denne sammenligningen.

Jeg bruker Safaris webinspektør for å se resultatresultater, jeg har deaktivert caches og skift + oppdater 10-15 ganger (omtrent hvert 2-3 sekund) for hver test for å få et anstendig gjennomsnitt av total ladetid, latens og varighet.

  • 45 Totalt antall filer (inkludert HTML-dokument)
  • 561.13KB Samlet kombinert filstørrelse

Vanlig webverten

Her er resultatene når det blir hostet via min vanlige webverten. Sortert etter latens.

  • 1.82-1.95 Sekunder total ladetid
  • 90ms raskeste ventetid (siste test)
  • 161ms Sakte latens (siste test)
  • ~ 65% av bildene hadde en ventetid på mindre enn 110ms

Sortert etter varighet.

  • 92ms raskeste varighet (siste test)
  • 396ms Sakte lengde (siste test)

Amazon S3

De nøyaktig samme filene ble brukt til testing av S3. Sortert etter latens.

  • 1,3-1,6 sekunder total ladetid
  • 55ms raskest ventetid (siste test)
  • 135ms Sakte latens (siste test)
  • ~ 90% av bildene hadde en ventetid på mindre enn 100 ms

Sortert etter varighet.

  • 56ms raskeste varighet (siste test)
  • 279mS Sakte lengde (siste test)

S3 er raskere enn min vanlige webverten, men bare marginalt. Hvis du ikke har lyst til å rote rundt med en CDN, er S3 fortsatt et godt alternativ for å gi nettstedet ditt et anstendig hastighetsforhøyelse. Jeg anbefaler fortsatt å bruke en CDN, og vi vil se hvorfor i denne neste testen.

Amazon CloudFiles

De nøyaktig samme filene ble brukt til å teste CloudFront.

  • 750-850ms Total ladetid
  • 25 ms raskeste ventetid (siste test)
  • 112ms Sakte latens (siste test)
  • ~ 85% av bildene hadde en ventetid på mindre enn 55 ms.
  • Bare en fil hadde en ventetid på mer enn 100ms.

Sortert etter varighet.

  • 38 ms raskeste varighet (siste test)
  • 183ms Sakte lengde (siste test)

Sammenligning

Her er en rask nedbryting av ytelsesjämförelsen mellom min vanlige webverten og de samme filene på Amazons CloudFront-tjeneste.

  • 1,82-1,95 sekunder mot 0,75-0,85 sekunder total ladetid (~ 1,1 sekunder raskere)
  • 90ms vs 25ms raskeste latens (65ms raskere)
  • 161ms vs 112ms sakte latens (49ms raskere)
  • CloudFront: Bare en fil med latens større enn 100ms og 85% av filene med latens mindre enn 55ms
  • Vanlig webverten: Bare 65% av filene hadde en ventetid på mindre enn 110ms

Varighet sammenligning

  • 92ms vs 38ms raskeste varighet (54ms raskere)
  • 396ms vs 183ms Sakte lengde (213ms raskere)

50ms eller til og med 100ms høres ikke ut som en veldig lang tid å vente (0,1 sekunder), men når du gjentar det for 30, 40, 50 eller flere filer, kan du se hvordan det raskt legger opp til sekunder.

Visuell sammenligning

Her er en rask video for å vise hvor merkbar økningen i ladetiden er. Jeg har deaktivert caches og gjør en tvunget oppdatering (shift + refresh) for å sikre at bildene ikke blir cached.

Andre måter å øke ytelsen på

Det finnes flere andre måter å øke nettstedets ytelse når du bruker en CDN.

  • Opprett forskjellige underdomener for ulike typer filer for å maksimere parallelle nedlastinger. For eksempel laste bilder fra "images.jremick.com" og andre filer som skript og CSS fra "cdn.jremick.com". Dette vil tillate flere filer å lastes parallelt, og reduserer total lastetid.
  • Gzip-filer som JavaScript og CSS
  • Konfigurer ETags

Se Best Practices for å øke hastigheten på nettstedet ditt for mer.

Betjener Gzipped-filer fra CloudFiles

Et av alternativene ovenfor for å øke ytelsen enda mer, var å levere gzipped-filer. Dessverre er CloudFront ikke i stand til automatisk å avgjøre om en besøkende kan akseptere gzipped-filer eller ikke, og servere den riktige. Heldigvis støtter alle moderne nettlesere gzipped-filer i disse dager.

Opprett og last opp dine Gzipped-filer

For å kunne betjene gzipped-filer fra CloudFront, kan vi gi vår nettside noen logikk for å betjene de riktige filene, eller vi kan sette innholdskoding og innholdstype på noen få bestemte filer for å holde ting litt enklere. Gzip filene du vil ha, og gi nytt navn til dem, slik at det ikke slutter .gz. For eksempel vil "filename.css.gz" bli "filename.css" eller for å minne deg på at det er en gzipped-fil, navnet den "filename.gz.css". Last opp gzipped-filen til plasseringen i din S3-bøtte du vil ha (ikke glem å sette ACL / Tillatelsene).

Hvis du ikke er sikker på hvordan du gziper en fil, kan du se http://www.gzip.org (OS X kan gjøre dette i terminal)

Angi innholds-koding og innholdstype

Vi må angi innholdsinnkoding og innholdstype (hvis det ikke allerede er angitt) på våre filer, slik at når du blir bedt om det via nettleseren, vet det at innholdet er gzipped og vil kunne dekomprimere det riktig. Ellers vil det se slik ut.

Vi kan gjøre dette enkelt med Bucket Explorer. Når du har lastet ned den, skriver du inn AWS Access Key og Secret-tasten for å logge deg på din S3-konto. Finn gzipped-filen du lastet opp tidligere, høyreklikk og velg "Oppdater MetaData".

Som du kan se, har det allerede innholdstype satt til tekst / css, slik at vi ikke trenger å angi det (javascript ville være tekst / javascript). Vi trenger bare å legge til riktig innholds-koding. Klikk på "Legg til" og i popup-dialogboksen skriv inn "Content-Encoding" i Nøkkel-feltet og "gzip" i feltet Verdi. Klikk på OK, deretter Lagre og du er ferdig! Nå vil nettleseren se filen riktig.

Gzipping en fil kan i stor grad redusere filstørrelsen. For eksempel var dette test stilarket rundt 22KB og ble redusert til omtrent 5KB. For bloggen min har jeg kombinert alle mine jQuery-plugins med jQuery UI-faner. Etter minifisering ble den redusert til 26,49KB, etter å ha blitt gzipped ble den redusert til 8,17KB.

Konklusjon

Det er mange måter å øke ytelsen til nettstedet ditt, og etter min mening er de verdt å prøve. Hvis besøkende bare er 0,5 sekunder eller enda 1 sekund fra å forlate nettstedet ditt, kan en CDN holde det som skjer. I tillegg er de fleste av oss fartsfrekvenser uansett, så hvorfor ikke skru opp ytelsen til nettstedet ditt hvis du kan? Spesielt hvis det kunne spare deg for penger i prosessen.

Hvis du har spørsmål, vennligst gi meg beskjed i kommentarene, og jeg vil prøve å svare på dem. Takk!

  • Følg oss på Twitter, eller abonner på Nettuts + RSS-feed for flere daglige webutviklinger og artikler.