HTTP Caching in Web Application

HTTP CACHING IN WEB APPLICATIONS

MARTINS SIPENKO


ABOUT ME

▸ Worked with IT since around 2002

▸ Lead engineer @KASKO, a fintech startup

▸ Student at University of Latvia

▸ AWS Certified


@MARTINSSIPENKO


WHY HTTP CACHING?


WHY HTTP CACHING?

▸ Decrease latency

▸ Decrease server response times

▸ Decrease the costs of origin servers

▸ Decrease the costs of data transfer

▸ ...


HOW HTTP WORKS?


HOW HTTP WORKS?

▸ Client & OriginCLIENT ORIGIN


HOW HTTP WORKS?

▸ Client & Origin

▸ Request & ResponseCLIENT ORIGIN

Request

Response


HOW HTTP WORKS?

▸ Client & Origin

▸ Request & Response

▸ HTTP Headers

CLIENT ORIGINRequest

Response

$ curl -v https://example.com > /dev/null > GET / HTTP/1.1 > Host: example.com > Accept: */* > < HTTP/1.1 200 OK < Server: nginx < Date: Wed, 25 Feb 2016 16:45:00 GMT < [1024 bytes data]

{{

Request headers

Response headers

Curl command

Response data


HTTP HEADERS

▸ Components of the request and response messages

▸ Define the operating parameters of HTTP transaction

▸ Two groups

▸ Defined by RFC standard

▸ Custom (X-*)


HTTP HEADERS

Accept, Accept-Charset, Accept-Datetime, Accept-Encoding, Accept-Language, Accept-Ranges, Access-Control-Allow-Origin, Age, Allow, Authorization, Cache-

Control, Common, Connection, Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range,

Content-Security-Policy, Content-Type, Cookie, Date, DNT, ETag, Example, Expect, Expires, Field, From, Front-End-Https, Host, If-Match, If-Modified-Since, If-None-

Match, If-Range, If-Unmodified-Since, Last-Modified, Link, Location, Max-Forwards, Origin, Permanent, Pragma, Proxy-Authenticate, Proxy-Authorization, Proxy-

Connection, Public-Key-Pins, Range, Referer, Refresh, Response, Retry-After, Server, Set-Cookie, Status, Strict-Transport-Security, TE, Trailer, Transfer-Encoding, Upgrade,

User-Agent, Vary, Via, Warning, WWW-Authenticate, X-ATT-DeviceId, X-Content-Security-Policy, X-Content-Type-Options, X-Forwarded-For, X-Forwarded-Proto, X-

Frame-Options, X-Http-Method-Override, X-Powered-By, X-Requested-With, X-UA-Compatible, X-Wap-Profile, X-WebKit-CSP, X-XSS-Protection, X-*


HTTP HEADERS









CACHING: CLIENT SIDE ONLY

ORIGIN

CLIENT 1 CLIENT 2 CLIENT 3 CLIENT N

BROWSER CACHE

BROWSER CACHE

BROWSER CACHE

BROWSER CACHE

Time


LETS ADD CACHING PROXY


CACHING: WITH CACHING PROXY

ORIGIN


BROWSER CACHE

BROWSER CACHE

BROWSER CACHE

BROWSER CACHE

CACHING PROXIES

Time


THE BENEFITS

▸ Less requests over wire if content is available locally

▸ Less origin hits

▸ Content served by cache

▸ No need to regenerate content

▸ Can be distributed globally over regions (CDN)


SOME NUMBERSCache time (minutes) Hit Ratio Request to Origin / Hr

1 99.8% 60

5 99.96% 12

20 99.99% 3

60 99.997% 1

86400 99.9998% <1

500 Requests per minute


CONDITIONAL REQUESTS



▸ Way to check if content has been updated since

▸ Can be used to reduce response times

▸ Origin returns either:

▸ 200 OK

▸ 304 Not Modified



ORIGIN


BROWSER CACHE

BROWSER CACHE

BROWSER CACHE

BROWSER CACHE

CACHING PROXIES

Time

200

304

200

304

200

304

200

304


CONDITIONAL REQUESTS: CODE

<?php

$ts = 1456419010; // Comes from DB or memory cache $last_modified = gmdate('r', $ts); header('Last-Modified: ' . $last_modified);

if ( isset($_SERVER['HTTP_IF_MODIFIED_SINCE']) && $ts <= strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) ) { header('HTTP/1.1 304 Not Modified'); exit(0); } sleep(5); // Do something very hard


CONDITIONAL REQUESTS: FIRST REQUEST

$ time curl -v https://example.com > /dev/null > GET / HTTP/1.1 > Host: example.com > < HTTP/1.1 200 OK < Server: nginx < Date: Thu, 25 Feb 2016 16:50:10 GMT < Last-Modified: Thu, 25 Feb 2016 16:50:10 GMT< [data not shown]

real 0m5.020s user 0m0.005s sys 0m0.006s

http://example.com


CONDITIONAL REQUESTS: SUBSEQUENT REQUEST

$ time curl -v https://example.com \ -H "If-Modified-Since: Thu, 25 Feb 2016 16:50:10 GMT" > /dev/null > GET / HTTP/1.1 > Host: example.com > If-Modified-Since: Thu, 25 Feb 2016 16:50:10 GMT> < HTTP/1.1 304 Not Modified < Server: nginx < Date: Thu, 25 Feb 2016 16:51:10 GMT < Last-Modified: Thu, 25 Feb 2016 16:50:10 GMT < [data not shown]


http://example.com


BUT


THERE ARE ONLY TWO HARD THINGS IN COMPUTER SCIENCE: CACHE INVALIDATION AND NAMING THINGS.

-- PHIL KARLTON


AN EXAMPLE PROBLEM

▸ A blog post stored in DB table

▸ Tags associated to that blog post

▸ Adding new tags does not update the post itself


AN EXAMPLE PROBLEM




LAST MODIFICATION TIME HAS NOT CHANGED


AN EXAMPLE PROBLEM




LAST MODIFICATION TIME HAS NOT CHANGED

ENTITY TAG CAN BE USED INSTEAD


CONDITIONAL REQUESTS: CODE

<?php

$last_mod = 1456419010; // Comes from DB or memory cache $last_mod_of_linked_resource = 1456419010; // Comes from DB or memory cache $etag = md5($last_mod . $last_mod_of_linked_resource); header('ETag: ' . $etag);

if ( isset($_SERVER['HTTP_IF_NONE_MATCH']) && $_SERVER['HTTP_IF_NONE_MATCH'] === $etag ) { header('HTTP/1.1 304 Not Modified'); exit(0); } sleep(5); // Do something very hard


CONDITIONAL REQUESTS: FIRST REQUEST

$ time curl -v https://example.com > /dev/null > GET / HTTP/1.1 > Host: example.com > < HTTP/1.1 200 OK < Server: nginx < Date: Thu, 25 Feb 2016 16:50:10 GMT < ETag: 228c662b04e31dc303d380ad03c2bc0b< [data not shown]


http://example.com


CONDITIONAL REQUESTS: SUBSEQUENT REQUEST

$ time curl -v https://example.com \ -H "If-None-Match: 228c662b04e31dc303d380ad03c2bc0b" > /dev/null > GET / HTTP/1.1 > Host: example.com > If-None-Match: 228c662b04e31dc303d380ad03c2bc0b> < HTTP/1.1 304 Not Modified < Server: nginx < Date: Thu, 25 Feb 2016 16:51:10 GMT < ETag: 228c662b04e31dc303d380ad03c2bc0b < [data not shown]


http://example.com


THE BENEFITS

▸ Revalidation could less expensive

▸ Amount of data transferred decreases

▸ Stale-While-Revalidate can be used on caching proxy level (if supported)


TOOLS FOR CACHING PROXY

▸ Apache Traffic Server

▸ Varnish

▸ Squid

▸ Nginx (would not suggest)

▸ Amazon CloudFront CDN

▸ Other CDNs


HTTP HEADERS









CACHE CONTROL


CACHE-CONTROL

< Cache-Control: private, max-age=0, no-cache

public | private no-cache no-store max-age s-max-age

must-revalidate no-transform proxy-revalidate

DIRECTIVES

EXAMPLE


EXPIRES

< Expires: Sat, 04 Feb 1989 04:34:00 GMT

EXAMPLE


THE "VARY" HEADER


VARY

< Vary: Accept-Encoding, User-Agent

EXAMPLE

THE VARY HEADER LETS THE CACHES KNOW WHICH REQUEST HEADER VALUES TO USE FOR CACHE-KEY.


VARY

< Vary: Accept-Encoding, User-Agent

EXAMPLE

... > Accept-Encoding: gzip > User-Agent: curl > ... < Vary: Accept-Encoding, User-Agent ...

... > > User-Agent: curl > ... < Vary: Accept-Encoding, User-Agent ...

GZIP-CURL CURL

WITH Accept-Encoding WITHOUT Accept-Encoding


THAT'S ALMOST IT


FEW SUGGESTIONS

▸ Let your application add caching headers instead of web server

▸ Be smart about what you cache and for how long

▸ Think well about how you will invalidate cache

▸ Keep in mind that errors too can be cached


Q&A?


THANKS!

@[email protected]


J K L

PLEASE GIVE FEEDBACK!

HTTP Caching in Web Application

Technology