Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Caching in Drupal 8


Published on

In this short presentation, Subhash Yadav of Valuebound has explained about “Caching in Drupal 8.” A cache is a collection of data of the same type stored in a device for future use. Caches are found at every level of a content's journey from the original server to the browser.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Caching in Drupal 8

  1. 1. Drupal 8 Caching Subhash Yadav
  2. 2. A cache is a stored copy of a resource so future requests for that resource can be served faster. The data stored in a cache might be the result of an earlier computation, or the duplicate of data stored elsewhere. Caches are found at every level of a content's journey from the original server to the browser. What is cache?
  3. 3. Why Caching? ● Faster than recomputing a result or reading from a slower data store; thus the, more requests can be served from the cache, the faster the system performs i.e. maximum output with minimum latency. ● Eases the load of the server ● Improves responsiveness
  4. 4. HTTP Headers HTTP Headers is where caching information is exchanged between the origin server and cdn, proxies including varnish all the way to the browser. Example : HTTP/1.x 200 OK Transfer-Encoding: chunked Date: Fri, 27 Nov 2017 04:36:25 GMT Server: LiteSpeed Connection: close X-Powered-By: W3 Total Cache/0.8 Expires: Fri, 27 Nov 2017 05:36:25 GMT Etag: "pub1259380237;gz" Cache-Control: max-age=3600, public Content-Type: text/html; charset=UTF-8 Last-Modified: Sat, 28 Nov 2009 03:50:37 GMT Content-Encoding: gzip Vary: Accept-Encoding, Cookie, User-Agent
  5. 5. The Expires header sets a time in the future when the content will expire. This header is probably best used only as a fall back. Expires
  6. 6. A unique hash identifier of the cacheable object that the browser caches. Whenever a cached response is requested again, browser checks with server if the eTag of the response is modified. If response is not modified server returns 304 not modified else 200 along with new response & new eTag. Etag
  7. 7. The date-time this cacheable object was last cached. (Similar to eTag) Last-modified
  8. 8. When a cache receives a request that can be satisfied by a cached response that has a Vary header field, it must not use that cached response unless all header fields as nominated by the Vary header match in both the original (cached) request and the new request. This can be useful for serving content dynamically. Vary
  9. 9. Each resource can define its caching policy via the Cache-Control HTTP header. Cache-Control directives control who can cache the response, under which conditions, and for how long. Cache-Control
  10. 10. no-cache: Indicates that the returned response can't be used to satisfy a subsequent request to the same URL without first checking with the server if the response has changed. no-store: It simply disallows the browser and all intermediate caches from storing any version of the returned response. public / private: If the response is marked as "public", then it can be cached, even if it has HTTP authentication associated with it, and even when the response status code isn't normally cacheable. private marked responses are typically intended for a single user, so an intermediate cache is not allowed to cache them but browser can cache them. Cache-Control Directives
  11. 11. max-age : Configures the maximum age that the content may be cached before it must revalidate or re-download the content from the origin server. This replaces the Expires header for modern browsing. This option takes its value in seconds with a maximum valid freshness time of one year (31536000 seconds). s-maxage : This is very similar to the max-age setting, in that it indicates the amount of time that the content can be cached. The difference is that this option is applied only to intermediary caches. Cache-Control Directives
  12. 12. All things that either are directly renderable or are used to determine what to render provide cacheability metadata. Cacheability metadata consists of three properties: cache tags : For dependencies on data managed by Drupal, like entities & configuration. cache contexts : For variations, i.e. dependencies on the request context. cache max-age : For time-sensitive caching, i.e. time dependencies Cacheability metadata
  13. 13. Cache tags provide a declarative way to track which cache items depend on some data managed by Drupal. The role of the tags is to identify cache items across multiple bins for proper invalidation. In a typical scenario, a user may have modified a node that appears in two views, three blocks, and on twelve pages. Without cache tags, we couldn't know which cache items to invalidate. So we'd have to invalidate everything and sacrifice effectiveness to achieve correctness. With cache tags we can have both. Cache Tags
  14. 14. Syntax: “Thing:identifier” Example: node:5 -- cache tag for node entity 5 user:4 -- cache tag for user entity 4 node_list -- list cache tag for node $tags = array('node:1', 'user:7'); Drupal::cache()->set($cid, $data, CacheBackendInterface::CACHE_PERMANENT, $tags); // Invalidate all cache items with certain tags. DrupalCoreCacheCache::invalidateTags($tags); Cache Tags
  15. 15. ● Cache contexts provide a declarative way to create context- dependent variations of something that needs to be cached. ● Determines how to vary items according to request. ● Similar to D7 block constants like DRUPAL_NO_CACHE / DRUPAL_CACHE_PER_ROLE / DRUPAL_CACHE_PER_PAGE, but with many more options. ● Cache contexts are hierarchical in nature. Cache Contexts
  16. 16. Example : theme -- vary by negotiated theme. user.roles -- vary by the combination of roles $variables['#cache']['contexts'][] = 'url.path'; Cache Contexts
  17. 17. Cache max-age ● Cache max-age provides a declarative way to create time- dependent caches. ● Controls how long an item may be cached by number of seconds. ● 0 means cacheable for zero seconds, i.e. not cacheable ● DrupalCoreCacheCache::PERMANENT means cacheable forever, i.e. this will only ever be invalidated due to cache tags. (In other words: ∞, or infinite seconds)
  18. 18. ● Varnish is just a web-server in front of origin webserver. ● Also known as a caching HTTP reverse proxy. ● It can be used with cache tags to make cache invalidation easy. ● Every request to the origin web-server goes through varnish. ● If varnish doesn’t have a request cached, the request is passed to the backend. Upon response, varnish reads the response headers and if response is cacheable varnish caches the response for next similar requests. Varnish cache
  19. 19. ● Varnish will only cache resources that are requested through an idempotent HTTP verb, which are the verbs that do not change the state of the resources. ● HTTP verbs that Varnish can handle: GET, HEAD ● PUT, POST, DELETE, TRACE, OPTIONS cannot be cached by the varnish. ● Varnish default cache setting is 120 sec (2 min). Varnish cache
  20. 20. You need to do three things to make sure Varnish works well with the cache tags generated by Drupal: ● Update your Varnish VCL so it handles BAN requests properly. Location : /etc/default/varnish/default.vcl configuration.html#tagging Varnish cache
  21. 21. Varnish cache ● Send a cache tags header: Drupal's Purge module automatically configures Purge-Cache-Tags headers. ● Send a BAN request when content or configuration changes: Add an HTTP Purger using Generic HTTP Purger module. Configure a cron job to process the Purge queue.
  22. 22. Thank you