 Okay, guys. Hello. So today we're talking about engines and varnish full-page caching and how to implement it for Drupal. My name is Daniel Kanchev and I work for SiteGround, we're a web hosting provider and we specialize at hosting Drupal websites. So the first thing that I would like to say is thank you for staying up that late for myself. And after that, I would like to explain why you need full-page caching in the first place. First, obviously your website will be faster, much faster, because you don't need to execute any PHP code, you don't need to get queries to your database, and because of something that I hate to do, and it is called red while you're out at lunch. I hate my website or one of our clients' websites to go down because of my inspector traffic. And when you have full-page caching, you don't have to do that, because even if the backends are down, your caching server can actually serve content to your visitors. So what exactly is full-page caching? Anyone here familiar with it? Okay, awesome. So that's exactly what I expected. So let's say that you have a user, let's say his name is Pat, and because I like him in one way, let's make him in one way. So this guy is trying to open your website and what happens is that when he tries to open your website, the server goes to a patch or whatever web server you're using, after that you execute a PHP script, and after that a MySQL query. So the information goes up that chain, goes back to the server, and the HTML page is generated. So the user sees that. The thing is that this thing is slow, especially if you have to perform a query in a 30 or 50 gigs of data in your MySQL database. So what happens when you're using a full-page caching solution is that you cache that HTML and the next user that requests the same page gets the cache directly. So it gets the HTML page and you don't have to do PHP execution and the query to the database. So whenever you deliver cached HTML, it's incredibly faster. I've managed to optimize sites from 2.5 seconds loading time on their home page to 0.2 seconds, or 0.3 seconds. So in terms of Drupal, is full-page caching available? And the answer is both yes and no, because full-page caching through a worse process like engines and varnish is not available in Drupal 7. It is available because you can create cached pages and save them on your hard drive, but that's through the Drupal 4 and it's much slower to read the cached pages from the disks than it is to read them from the ramp of your server. So if you save the cached pages into the ramp of your server, you can get them instantly. And when you have caching servers all around every single continent, if you have users on, then you don't have the problem of latency. The cons in Drupal 7 is that as I mentioned, the full-page caching you get by default there first is not friendly for engines and varnish. Second, it does not provide easy invalidation. So what I mean by easy invalidation is that you get a page. So you perform a change of that page or a menu. And after that, how do you invalidate the cache if it's somewhere in the ramp of your server and it's cached by engines and or varnish? The problem is that Drupal 7 does not know how to talk to those revered processes. So it doesn't add any HTTP headers to the response that is provided by the server and the engines process does not know how to handle that request. The other thing is that full-page caching is not enabled by default in Drupal 7. So what about Drupal 8? We're all excited about it. And me too, mainly because it supports both varnish and Nginx because it provides HTTP headers that can tell your reverse proxy hey, this page can be cached, for example, two hours or three hours. And engines or varnish could be configured to look at the HTTP headers and after that cache the page and that's without any plugin. It's easy to invalidate cache. You just check the expiration date in the HTTP headers and you set an expiration for the cache and it's enabled by default. So as I mentioned, the reverse proxy is something that could either be a different server that stands before your web server or it could be a service running on your existing servers. So when it's a service running on your existing servers, it's much easier to configure it because you don't have to set different IP addresses you don't have to care about if it's public or private networking and the latency between those. So in Drupal 7, how do you handle full-page caching through a reverse proxy? There are three things you have to do. You have to install either varnish or Nginx. You have to create a configuration file for one of those and you have to install a plugin or think of a similar solution that could be integrated into Drupal so that you can invalidate the cache. So the first one is easy. You just go to the right pole, download whichever reverse proxy you want to use and that's it. But the second two, they're very difficult. Mainly because you have to integrate your reverse proxy with your Drupal installation. So on our servers we have a solution which is called the supercache. So we created a plugin that works for Drupal 6 and Drupal 7. It provides caching validation and you can also define certain URLs to be blacklisted. So for example, you don't want a page to be cached at all, you just define that URL in the list and it will automatically be excluded. The other thing is that we have custom Nginx configuration. I'll show you some of the configurations for Nginx right now. And what we're really proud of is that this is suitable for shared hosting machines. If you have like, I don't know, 100, 200 customers, you can do the same on your servers. You can put them on a cluster, you can put them on one single dedicated server, it depends on the clients and after that use similar solutions to provide full pay caching for all of them. So as I mentioned, cached copies of the pages are kept in the RAM and that's match faster. So here is some of the configuration of the Nginx server that we're using. So we're using maps, as you can see, and we have to define certain conditions when you can page a cached page or not. So for example, if you look at the second map which says HDTT cookie, if this cookie is present and that cookie is added by the plugin that we install to every single Drupal installation, then in that case, we'll skip the caching for that request. So we set the cookie in the plugin, for example, for locked-in users because they don't need to see a complete cached viewer e-commerce card page and this way you'll be sure that they won't see any outdated content or for example, the card with another customer. As you can see in the third map, we have defined like addresses, common addresses that are present in Drupal that should not be cached as well. So anything from the dashboard that contains the admin or the user should be excluded from the cache. So pretty much that's the Nginx configuration, but the trick is to make the plugin or your integration to use like a cookie or a header or something like that to make sure that they work together and to provide cached pages only to the visitors that need to see cached pages. So here's some of the code. So if you look at the code you see that the most important part is that we add a header which is called xcache-enabled and this plugin is set to either true or false. So if you open a page and this page has the xcache-enabled set to true this means that this page is cacheable. So this could be your front page if it doesn't change for locked-in users. It could be, I don't know, an about page or whatever. And if this header is set to true, the reverse proxy will just copy the whole HTML, put it in RAM, and after that the second user that opens the same page will get it from the cache. As you can see there is also expiration for some cookies that we add to locked-in users and pretty much that's the magic. So right now I want to show you some more code out of the plugin. Let me just drag that here and I'll just put the code a little. So those are our hooks that automatically detect changes in your Drupal application. So if we create a new page or you update a menu link you don't have to purge the cache every single time you do that. These hooks will just detect that you have edited something in the dashboard and they will connect to the caching server and invalidate the cache copies of this page. If I scroll down I can also show you how exactly the cache is cleared but pretty much it is just like a get or post query but it is called purge or ban. So the engines reverse proxy or the varnish reverse proxy they also understand other commands such as ban and purge and when you say purge a certain URL they just remove the certain URL from the cache and everything else remains cached. Let's go back to the presentation. There we go. So if you want to check the code for our plugin you can go to that address and download it. It's available for everyone but as of now it works only on our servers because as I mentioned you need to have a configuration that should be able to work together with the plugin. However my opinion is that if you check the code and you are a really good programmer and I think that Drupal programmers are really good programmers because of the stuff that goes into core I'm sure that you'll be able to understand how to pretty much match the things that I mentioned and try to your own engines configuration that will be even more suitable for your own website than the default one that we have for most of our clients. So what's the roadmap for us personally? I'm excited to see Drupal 8 so right now we're working on support for Drupal 8 in our plugin and once it's ready it will be uploaded to the Drupal plugins modules directory and we'll be using cache tags and metadata for invalidation. Cache tags and metadata will be used by default in Drupal 8 for caching. So for example you can add some metadata to a post or a category and you should know that everything that belongs to this category should not be cached or you should, for example, set the cache to one hour. And the next thing that we want to do is implement user-based caching. So right now people that log into your site they do not use the advantage of caching. The problem is that right now in Drupal 7 it's not very easy to understand if you can cache just certain parts of this page and with Drupal 8 that will be possible because of cache tags and metadata. So if you want to read more about how to set up varnish and engines for your websites I strongly advise you to check all those groups because Drupal has groups about engines and varnish, there are multiple other plugins in the plugin directory that you can check the code of to be able to understand how to clear and validate the cache and the last two articles I would strongly suggest you to read them because they are written by the guy who wrote most of the caching code in Drupal 8. So you can also get the slides at that address because I see some of you are taking pictures just download them, the addresses, the URLs, everything is in there and the last thing that I want to say is don't forget the Friday Sprints. Drupal 8, the caching in Drupal 8 wouldn't be possible without all the people that contribute all the time and it was my first time going to Sprints several months ago in Los Angeles during the Drupal code so I strongly encourage you to go on Friday and do your best to contribute on whatever you think you're good at documentation, code, whatever you think so that's for me and thank you very much if you have questions go ask them now other than that you can come downstairs to our booth it's right next to the entrance at the right side of the entrance it's a handmade booth, you can't miss it Do you also achieve a simple kind of caching by handling VTAC and setting the file type? What was that question? I think that the question was can you just simply use the cached control HTTP headers and the engines should be able to understand when to cache and when to invalidate a page without all these questions set up, right? So we've talked about it and my answer is both yes or no if you have a website that you are sure you can use only the cached control header then you can use it, but on our platform we host thousands of Drupal websites so you can get a website with a caching plugin that is misconfigured and the cached control header is just not set up properly or for example let's say that the cached control headers that you send are generated on one server with a time zone configured somewhere in Europe and your caching servers, your engines caching servers are somewhere else, so what do you do? In that case you have to recalculate and it can become much complex Well, that is possible but yeah, that's possible but as I said it depends on the website when you have to come up with something available for many websites you just have to think of caching plugins for example if you can install on Drupal they can pretty much screw the headers up Okay, if you don't have any other questions I would like to thank you for your time and have a great Drupal come!