Recommended
More Related Content
What's hot
What's hot (20)
Similar to Cache bonanza
Similar to Cache bonanza (20)
Recently uploaded
Recently uploaded (20)
Cache bonanza
- 1. Cache bonanza Harald Schult Ulriksen @hsulriksen http://aurum.no
- 3. HTTP Cache Output cache Application cache
- 4. RFC 7234 - HTTP/1.1 Caching
- 5. RFC 7234 - HTTP/1.1 Caching A stored response can be considered fresh if the response can be reused without validation
- 6. RFC 7234 - HTTP/1.1 Caching Although caching is an entirely OPTIONAL feature of HTTP, it can be assumed that reusing a cached response is desirable and that such reuse is the default behavior when no requirement or local configuration prevents it. Therefore, HTTP cache requirements are focused on preventing a cache from either storing a non-reusable response or reusing a stored response inappropriately, rather than mandating that caches always store and reuse particular responses.
- 7. RFC 7234 - HTTP/1.1 Caching Freshness • s-max-age • max age • expires • heuristics
- 8. RFC 7234 - HTTP/1.1 Caching Freshness • s-max-age • max age • expires • heuristics Last modified Last requested Now Tid
- 9. RFC 7234 - HTTP/1.1 Caching Freshness • s-max-age • max age • expires • heuristics Validation - RFC 7232 • Etag • Last-Modified • If-none-match • If-modified-since
- 10. RFC 7234 - HTTP/1.1 Caching Linker • RFC 7234 - https://tools.ietf.org/html/rfc7234 • RFC 7232 - https://tools.ietf.org/html/rfc7234 • Mark Nottinham - https://www.mnot.net/cache_docs • Darrel Miller - http://bizcoder.com/caching-is-hard-draw-me-a-picture • Jesse Wilson – https://publicobject.com/2015/03/26/how-do-http- caching-heuristics-work
- 11. Application cache • Local cache • Redis • Redis with msgpack • Distributed layered cache • With synchronization • Fun with Redis
- 12. Local cache
- 13. Demo
- 14. Remote cache
- 15. Remote cache
- 16. Remote cache
- 17. Redis • http://redis.io • Key value store + data structures • By Salvatore Sanfilippo / @antirez • Ansi C • Single threaded • Lua in server • Microsoft research port to windows – nuget redis-64 • On Azure, AWS og Google cloud.
- 18. Demo
- 19. In production
- 20. Layered distributed cache Application Local cache Remote cache Slow thing
- 21. Demo
- 22. Pub-sub 1 2 3 4 1.Store data 2.Send publish notification 3.Publish notification 4.Get data
- 23. Demo
- 24. In production
- 25. In production
- 26. Other datastructures in Redis Search for «An introduction to data types and abstractions» • Key/Value • Lists • Hashsets • Set • Sorted set • Hyperloglog • Geospatial
- 27. Lua script Atomisk operasjon. Ingen rollback. Kan lastes opp til server og kalles basert på hash.
- 28. Add now-playing
- 29. Read
Editor's Notes
- Blackfriday.
- Black Friday. Skatteetaten. Valg Før vi fortsetter – det er mange patterns, og mye å tenke på for å skalere. Cache er bare ett av dem.
- Når man snakker om cache så er det mange som tenker på CDN. Idag skal, vi la CDN være CDN, og gå utifra at vi hoster bilder og annet statisk innhold hos en CDN, så kan vi se på cache rundt de delene av tjenesten som leverer data. Hvis vi ser på veien fra en klient til et api så er det overordnet 3 cache lag, http cache – gjerne client side, en eller annen output cache som står rett på tjenesten men etter at data er sendt, også har vi application cache. For de som synes CPU cache er spennende, så må jeg skuffe dere. Jeg har lyst til å snakke om HTTP cache pga. etags og last modified header. Har vi orden på dette og en god applikasjonscache kommer vi usedvanlig langt.
- Målet med HTTP cache er å merkbart forbedre ytelsen ved å gjenbruke svar fra en tidligere forespørsel. Samtidig er det viktig at man opprettholder semantikken i protokollen, med GET/PUT/DELETE etc. Caching er valgfritt, men man kan gå utifra at gjenbruk av et tidligere svar er vanlig oppførsel.
- Dette betyr at det er to ting som er viktig for å kunne avgjøre om en lagret respons kan brukes, det er om den er kan betraktes som gyldig, eller om den må valideres. Når vi vet at caching kan sees på som standard, og at gyldighet og validering er de viktige tingene, så er er det verdt å legge merke til at RFC 7234 ikke er skrevet som kriterier som skal til for at man skal kunne cache, men hva som skal til for å hindre lagring av responser som ikke kan gjenbrukes, eller gjenbruke en respons på feil grunnlag.
- Bruk tid på å la de lese. Time selv. Drikk vann. Så, specen sier ingen ting om at man alltid skal lagre xyz, det er hva vi ikke skal lagre og hva vi ikke kan gjenbruke. Når vi vet at caching kan sees på som standard, og at gyldighet og validering er de viktige tingene, så er er det verdt å legge merke til at
- Freshness Når en respons er gyldig, så behøver vi ikke snakke med remote server. Den kan leveres direkte fra cache. Dette er selvfølgelig det mest effektive og det vi ønsker. For at at side skal kunne ansees som fresh vurderes s-max-age, max-age og expires før man evt. prøver å beregne om cache er fresh.
- We use the time between last requested at and last modified at to estimate how frequently a document is edited. If a page was modified 5 minutes before the request, it’s assumed to be frequently modified. If it was last modified 5 years before the request, it’s assumed to be infrequently modified. A page is fresh for 10% of that duration: 10% of 5 minutes is 30 seconds; 10% of 5 years is 6 months. A page is considered fresh until that 10% has elapsed since the document was last requested. An example. 100 I mellom last modified og last requested. Ni dager etter ber vi om nytt. Fresh. Levert fra cache. 11 dager etter. Fører til validation request til server .
- Validering skjer ved bruk av headere som gjør at man kan få en 304 respons fra server. I tillegg kan validering gjøres ved put og delete, slik at operasjoner kun utføres hvis server state ikke har endret seg i mellomtiden. To headers – last modified – sum av flere deler – og da den som er sist endret. Utfordringen med last modified er at den ikke har høyere oppløsning enn sekund, og derfor i utgangspunktet er å betrakte som en svak validator. Når det gjelder etag er de å anse som sterke, men hvis den ikke er det så MÅ serveren markere den som weak. F.eks hvis man bruker en hashing algoritme som ikke garanterer uniqueness. En server bør sende både etag og last modified. En klient skal sende entity-tag med i validerings request. (med passende if-match eller if-none-match) Bør sende med last modified og if-modified-since If-none-match, må bruke svak godkjenning, brukes hovedsaklig med get requests. Hvis det er en som passer skal server svare med 304 for get eller head. 412 for alle andre metoder. Kan også brukes ved put for å sikre at server ikke har en eksisterende representasjon. Race condition/lost update. If-modified-since Skal ignoreres hvis det er en If-None-Match header med requesten. Klienten bør gjenbruke last-modified fra cachet respons for å få riktig dato (husk å droppe millisekunder på server siden). Hvis server har en dato som er før eller lik last-modified så skal den svare med 304. ------- If-match – etag – pre-condition. Hvis server ikke har denne, 412. Hvis det er state change og resultatet av operasjonen alt er gjort så kan den levere 2XX. Kan ignoreres av cache da den ikke gjelder lagret respons. If-unmodified-since brukes også til å sikre state change på riktig grunnlag. ------
- Enkelt og greit, i minne, i context. Kan være så enkelt som et static dictionary. Men kjekt med minnebegrensning, ttl og eviction. Mutability Cache aside pattern. – consistency, priming, eviction. Demo – god tid. Vis interfaces, vis kode.
- Bruk god tid. Gå igjennom interfaces, forklar hva vi egentlig ser. Netling
- Hvorfor remote cache? Skalering, lastbalansering. Synkronisering. Kalle instanser. Hva skjer når man går over til en remote cache? Vi får 2 problemer - IO og serialisering Husk, minne er lynkjapt.
- Er også i clustret versjon med master. Finnes mange løsninger på dette utover redis cluster, twemproxy, monaco, master slave. Sikkerhet, i utgangspunktet vid åpen. Støtter ssl + auth key. En connection til server. Pipelining
- Demo Redis – install, run, client, monitor, info Demo prosjekt. Vis kode. Serialisering og implementasjon Single instance Husk å lukke monitor Demo prosjekt many
- Implementasjon Demo
- Krever kontroll på data. Nok en grunn til at database som integrasjonspunkt mellom applikasjoner er en sikkelig dårlig idé. Etags – last modified! Cache aside, hva skjer når det mangler i all cache og man får mange requests samtidig?
- Implementasjon Demo
- Key/Value String. Kan gjøre bit operasjoner og INRC DECR (api throtling) Lists Linked list. Kan brukes som kø/log Hashset Lagring av objekter. Kan lønne seg å bruke ett hashset med mange hashes (key) fremfor key/value pairs. Sets Kan gjøre union/intersect m.fl SortedSet Top Score, Sortering i tid, Hyperloglogs Telle forferdelig store ting med lite minne. Omtrentlig nøyakti Geospatial
- Key/Value String. Kan gjøre bit operasjoner og INRC DECR (api throtling) Lists Linked list. Kan brukes som kø/log Hashset Lagring av objekter. Kan lønne seg å bruke ett hashset med mange hashes (key) fremfor key/value pairs. Sets Kan gjøre union/intersect m.fl SortedSet Top Score, Sortering i tid, Hyperloglogs Telle forferdelig store ting med lite minne. Omtrentlig nøyakti Geospatial