proxy_cache_use_stale allows you to serve stale content in various scenarios when fresh content is not available. This saves a significant amount of work on the backend. That way when the first request is satisfied, the other guys will get it from the cache. The first directive, proxy_cache_lock, says that if there are multiple simultaneous requests for the same uncached or stale content nbsp – in other words, content that has be refreshed from Drupal – only the first of those requests is allowed through, and the subsequent requests for that same content are queued up. Then there’s some directives that we determined, based on testing, can improve performance even more in the microcaching case. That’s how we enable microcaching on a basic level within NGINX. We’ll see why that matters in a few minutes.Īnd there’s the inactive parameter, which deletes content whether or not it’s stale if it has not been accessed by a user for a given amount of time in this case, 10 minutes. It just sits there as stale content, which can be desirable. This is set by the proxy_cache_valid directive and marks an entry as being stale but does not delete it off NGINX. There’s another directive on the top there that says if content is inactive for 600 seconds (or in other words no one has accessed it for 10 minutes) it’s going to be deleted from the NGINX cache, whether it’s stale or not. proxy_cache_valid is the magic line here that will take in all the content that is cacheable and then say that for this content, we’re going to cache it for one second, and then we’re going to mark it as stale. Here’s a very simple NGINX configuration that enables caching. If you’re doing microcaching, updates can be taken care of just by leveraging existing caching mechanisms. That takes away a lot of the typical worries you have with caching, such as accidentally presenting old stale content to your users or having to go through all the hassle of validating and purging the cache every time you make a change.
The nice part of microcaching is you could set your microcache validity to one second and your site content will be out of date for a maximum of one second. By microcaching this content, which is to say caching it for a short amount of time – as little as 1 second – we can get significant performance gains and reduce the load on the Drupal servers. That’s personalized content, your shopping cart, your account data, stuff that you do not ever want to cache.īetween those two extremes, there’s a whole load of content (blog posts, status pages) that we consider dynamic content, but dynamic content that is cacheable. This is where you cache content that’s somewhere in the middle here on the scale between static content (such as images, CSS, stuff that’s typically easily cached and quite often put into some sort of CDN) and stuff that’s all the way on the right. Microcaching is a term you may or may not have heard. Varnish is an open source cousin of ours and we’re not trying to knock it, but these kinds of results show how the event‑driven architecture of NGINX that Floyd touched on earlier – and the way that we handle traffic within NGINX – allows us to scale to a level that other products and other projects are not always able to do. In the BBC’s testing, they found that with NGINX as a drop‑in replacement for Varnish gave them five times more throughput. They laid out all the details of their configuration and what they did to be able to get this performance difference on the BBC Internet blog. This screenshot here is from a BBC study of their Radix caching server.
Another less well‑known benefit with caching is that you’re saving deep compute cycles in the backend as well. Now, a request that would previously go and cause a PHP script to be executed on the Drupal servers is intercepted and served by NGINX, so you also get that performance improvement. Second, you’re also offloading that work from the Drupal servers. Caching provides many benefits to your site, but there are two main ones.įirst, by caching the content, you’re moving it closer to the user, so they can get it faster. You can also view the complete webinar on demand.įaisal: Once you have a server running Drupal 8 and NGINX properly, you can start looking at caching to improve performance. The first part focuses on site architecture and configuring NGINX for Drupal 8. It is the second of two parts, and is focused on caching and using NGINX as a load balancer. This post is adapted from a webinar hosted on January 20, 2016 by Floyd Smith and Faisal Memon of NGINX, Inc.
0 kommentar(er)
