[APPLAUSE] So hi everyone. 0:00 Can everyone hear me all right? 0:06 At the back? 0:07 Yes? 0:08 How are we feeling today. 0:08 >> Awesome. 0:10 >> Awesome. 0:11 People are feeling awesome. 0:11 I like that. 0:12 This talk's called Varnish In Action, making your 0:13 website bulletproof, and I hope we achieve that today. 0:15 So anyway, my name is Thijs. 0:18 Hi. 0:20 I know it's weird-sounding name but will do fine. 0:20 I'm ThijsFeryn on Twitter in case you wanna follow 0:25 me, heckle me, ask me questions, or just engage later. 0:27 As Ian told you guys, I work at a hosting company. 0:31 I'm a tech evangelist, which is a fancy term for talking to 0:35 people, taking an input to the company, and trying to do interesting stuff. 0:38 Again, repetition. 0:44 I am a, a board member at a PHP user group for Belgium, Netherlands and Luxembourg. 0:45 So that's three countries we're covering. 0:50 And I am Belgian, and that poses a problem 0:53 right now, because okay, I, no need to explain, right? 0:56 There is a World Cup game going on right now. 1:00 Belgium is playing right now. 1:03 I've seen the first half from my room. 1:04 And we're 0-1 behind Algeria on a penalty kick, so I will compensate 1:06 for that poor performance and represent my country right here, right now. 1:13 So what's Varnish? 1:18 I would like to see some hands, let's keep it interactive. 1:19 Oh, before we can continue, is anyone following 1:21 the game, the second half on the game? 1:24 [INAUDIBLE]. 1:26 >> Okay, Ian that's your responsibility, right? 1:28 If this score changes, just wave at me, >> I got it. 1:30 >> Okay, thanks man. 1:34 So what's Varnish? 1:35 Anyone familiar with Varnish? 1:35 Okay, cool. 1:37 I expect the other people either not to be familiar or a bit shy. 1:39 Anyway, a Varnish what is it? 1:44 It is, it does three things, or, it, it does caching. 1:46 It's actually a reverse proxy too. 1:50 A lot of people seem it as, see it as a load balancing system as well. 1:53 The people at Varnish themselves tend to call it an 1:56 HTTP accelerator, which is just a term that covers it all. 1:58 Why would we use such a system? 2:03 Anyone? 2:05 Why should we use a system that does caching or, or reverse proxying? 2:06 Anyone have an idea? 2:11 >> It's expensive for a website to gather more traffic. 2:12 >> Yeah, that's, that's one of the things. 2:17 What people use reverse proxies for is hiding the origin server, 2:18 that's something people usually do, SSL termination is a big one. 2:22 Varnish doesn't do that, spoiler. 2:27 Load-balancing, caching and compression. 2:28 And caching is the big one today. 2:31 Where, we'll mainly be focusing on caching. 2:32 And, what caching does for you, in, in 2:35 this modern-day and age, it's protecting your backend server. 2:37 Like, the term proxy, is, is, is old, we've 2:40 been using that term for, for more than a decade. 2:42 And back in the day these were 2:46 just regular forward proxies because internet connectivity was 2:47 kind of slow, and people needed a way to compensate for that, but that has changed. 2:51 We have broadband, very fast connections and we 2:55 shifted that to the other ends of the spectrum, 2:57 to the data center and because there's so 3:00 much connectivity, that lines get saturated boxes get attacked. 3:01 So we need to protect our backend server. 3:05 And that is exactly what this talk is about today. 3:07 Is it any good? 3:10 Is the question. 3:11 Can I see those hands again, who, who uses Varnish already? 3:12 Let's see, then tell me, is it good? 3:15 Is it good? 3:16 People think it's good. 3:17 I find it to be very good. 3:18 If you put it in front of your web server, it is so intelligent and so optimized. 3:20 It uses a lot of kernel tricks. 3:27 I won't discuss those right now, but the thing 3:29 is that memory and CPU usage you hardly see it. 3:32 There are websites that have 40 million 3:35 visitors a day with only two Varnish servers. 3:38 Why two? 3:41 Not because they get hit so much, because you need a fail over plan, of course. 3:41 If one falls down you need the other one, so it's a, it's a very good system. 3:45 And it's especially good when the pressure is on. 3:49 So, when you get a lot of visitors, tha's when you need to use it. 3:50 I tend to compare it to the blockbuster movie The Bodyguard. 3:54 Anyone see that one? 3:57 90s movie. 3:58 So, what essentially happens, and that is what Varnish does. 3:59 You put your varnish in front of your web server. 4:02 So Kevin Costner, Frank Farmer in the movie, is standing 4:04 in front of Whitney protecting her from evil, stalky fans. 4:07 I've been using this picture for a long time and I realized last week that this 4:12 is actually a horrible picture because Whitney Houston 4:17 died by over dose if I'm not mistaken. 4:19 So, too much HTTP traffic for her. 4:22 HTTP is the pro, I'm sorry if I insulted anyone. 4:26 [LAUGH] HTTP is the protocol, that, that we're gonna be using. 4:30 And we've been using it for a while. 4:35 And the caching, we've been using, we've been using it 4:36 since the 90s in browsers everyone familiar with browser cache? 4:39 I used to hate browse cache. 4:43 I use to absolutely hate it. 4:45 Why would I want a system that doesn't give me the latest updates? 4:46 Cuz it, it stores old content. 4:50 I don't want old content, I want new content. 4:52 I was kind of stupid, I was a kid back then. 4:55 But now I realize that there's, there's tremendous power in 4:57 HTTP, especially in terms of caching, you have a really good 5:00 cache control header that has a variety of, of, of 5:03 verbs you can use, and these are ones we often use. 5:08 We have the maxage and the s-maxage. 5:12 Max age is defined for browsers, s-maxage 5:14 is defined for servers, yes for proxy servers. 5:18 Varnish prefers s-maxage. 5:23 If it doesn't find an s-maxage it will take the maxage. 5:25 if it doesn't find that, it will just use this header, Expires, which is pretty 5:28 much the same thing, but in term, instead 5:32 of using relative timing it uses absolute timing. 5:35 But our problem's with browser cache, right? 5:40 And I'm preaching to the choir, browser cache, 5:41 you can flush it, so it defies the purpose. 5:45 Everyone has its own cache, there's no central cache. 5:47 Huge problems with browser cache, every now and then 5:51 I, I enable it when I have a slow connection. 5:55 But, connections, they're not fast enough, I guess. 5:59 A bit of history, before we start seeing some codes and doing some set up. 6:02 Varnish is invented by a Danish guy called Paul-Henning Kamp, 6:07 and he developed it for a Norwegian, newspaper called Verdens Gang. 6:11 It was a custom project. 6:16 He, he didn't build it to release it as an open source project, he built it 6:18 for Verdens Gang, and that was ordered by 6:22 Redpill Linpro, which is a Norwegian consulting company. 6:25 So they had Paul-Henning working on the project for Verdens Gang. 6:30 It was such a success that they decided to open source it. 6:33 And nowadays the product is so successful 6:36 that there's a separate company these days. 6:39 Varnish software they do enterprise. 6:42 Tools on top of it training professional services. 6:45 You know how that works, right? 6:48 With open source. 6:49 They find a way to fund the project. 6:50 It started out in 2005. 6:52 V1 2006. 6:53 V2 2008. 6:55 V3 which is still the most popular version in 2011. 6:57 And look what we have. 7:00 In 2014, April 29, so less than two months ago. 7:03 Version two. 7:06 A version four was released. 7:07 And that poses a bit of a problem in this talk, because version four is 7:08 not mainstream enough yet to be to just drop all the vtrees stuff on my slides. 7:11 But then again, if you're not familiar with Varnish and we want to send you out 7:17 with some, a brief overview it would be sad that I don't show you the latest. 7:21 So, it'll be like a trade off. 7:26 This is how you do it in V3, V4. 7:28 I know it's quite annoying, but I hope it will help you. 7:29 So, let's install it. 7:32 It's pretty simple. 7:33 We're all Linux people here? 7:35 Any Windows folks? 7:37 Windows is absolutely fine. 7:39 We have hybrid setups where we put Linux 7:40 boxes with Varnish right in front of IIS's. 7:43 But for the purpose of this talk we'll focus 7:45 on Linux and I'm more of a deviant Ubuntu guy. 7:47 So these are the installation procedures using 7:50 the APT get, Varnish has its own channels. 7:53 I would say don't depend on the operating 7:56 system channels because they tend to be outdated. 7:58 So go for eh, the ones that Varnish offers you. 8:01 And I put some color in it, the yellow color is the distribution. 8:03 So change that accordingly. 8:06 And V3, Varnish 3.0, you can change that with 8:08 4.0 and you have the most recent version available. 8:11 So once we've installed it we need to configure it of course. 8:14 And configuring it is quite easy. 8:17 There is a file that has your demon startup options, and you can 8:18 see at the minus A parameter points to port 80, which is just 8:22 saying on what, which port should it listen and it totally makes sense 8:25 to put it on 80 because that is the HTTP port of course. 8:29 And I didn't, before the colon, I didn't mention any 8:33 IP address so it just binds to everything it can find. 8:35 The minus T capital is the admin interface which is 8:38 a telnet kind of interface so it's not encrypted, be careful. 8:42 Don't put it open. 8:47 Minus F is where the magic happens. 8:48 It points to a VCL file, which stands for Varnish Configuration Language. 8:50 And is the sort of DSL to the main specific 8:55 language that we'll be using for caching policies request handling. 8:57 So this defines how Varnish should behave. 9:00 If we connect over to minus T, so over Telnet, 9:03 we should add a layer of security because it's not encrypted. 9:07 That's why there's a secret key there that will be used in a sort 9:10 of challenge system, and eventually the storage 9:12 is in RAM, malloc RAM, and 1 gigabyte. 9:15 So, that's it. 9:18 And if we open the VCL file, the only thing that needs to be in there is 9:19 a reference to the backend, and that's, in 9:23 this case on the local system on port 8080. 9:26 But, this sometimes requires changing some web server parameters. 9:28 So if you host your Varnish on the same box as your Apache or 9:35 your Engine X or whatever you're using you might want to change the ports. 9:38 I always use 8080. 9:42 So if you go to your process list and it 9:44 runs on 8080, some systems see it as HTTP alternative, 9:46 so it's actually considered as an alternative port for HTTP 9:49 or on another IP if you host it on another box. 9:53 Speaking of boxes, out of the box behavior is pretty common. 9:55 It respects your HTTP caching headers, which we've discussed a minute 10:00 ago, so those cache control headers expires headers, it will use those. 10:04 But what it wont do, and this is where you need to pay attention, because 10:08 this has bitten me in the ass, number of times when I started out with Varnish. 10:11 If it's a post, a delete, or a put it will not cache. 10:17 Why is that? 10:20 Anyone? 10:21 You can use a fancy word for it. 10:22 There is a fancy word for these kind of HTTP methods, anyone? 10:23 [UNKNOWN] >> Yes, there we go. 10:29 [UNKNOWN] is that what you were saying? 10:31 Okay, am I pronouncing it right? 10:33 I'm not a native English speaker. 10:34 Okay, thank you. 10:35 So what this actually implies is, if you use a post, a delete, or a put verb, it 10:36 actually changes the data, so and if it changes it, you can't cache it. 10:41 So Varnish will proactively pass these along to the backend. 10:47 If it sees cookies, it won't cache it, why? 10:51 Because cookies imply that there's user specific data. 10:54 And user specific data like, remember the shopping cart, hello Jack. 10:57 Well if everyone see's hello Jack, my name is Tase and I 11:02 see hello Jack, I know clearly something went wrong with the caching system. 11:04 I've made that mistake before. 11:08 Aggressive caching in shopping cart, went completely nuts. 11:10 Authentication headers also imply user specific 11:13 data, so it won't cache those hitters. 11:16 You know, those service that pop-ups. 11:18 Username, passwords. 11:20 Varnish won't cache those either. 11:21 If there is a set cookie header being sent from the back, so if the Apache 11:23 or whatever you're using is requesting the client 11:26 to store a cookie, Varnish won't cache either. 11:29 And if the TTLs, so the time to live, defined by 11:32 expires cache control, is equal zero or less than zero, it 11:35 wont cache either, and finally, and this is a new v4 11:39 feature, it will dig more in, into the grammar of cache control. 11:42 If it sees a no-cache, a no-store, or a private, it won't cache either. 11:46 So let's talk about cookies for a minute. 11:51 I personally don't quite like cookies, but they're out there. 11:54 I've heard in a new version of HTTP, which is decades still, 11:58 decades still to come so we have a lot of time yet. 12:01 There will look, be looking for a session mechanism, but in 12:05 the meanwhile we often use cookies for sessions or for other state, 12:08 mechanisms of state because HTP is is stateless protocol and we're trying 12:12 to figure out state in there so cookies are there for it. 12:17 And there's two kinds of cookies. 12:20 So if you got to a website you've never visited 12:23 before, your cookie store on your browser will be completely empty. 12:25 Once you connect with the server and the server 12:28 sends a set cookie, then it will be stored 12:31 on your local computer and every next request, the 12:33 cookie will be sent as well as a string. 12:36 So, that's what implies cookies and, and that way you know you're, 12:38 there are two kinds of cookies; set cookie and a regular cookie. 12:42 Okay, let's talk about the flow for a minute because that's an important one. 12:46 And I've, I've done three hour tutorials on this topic, and 12:49 that's where I tend to lose a lot of the people. 12:52 So I'll try to focus extra on the flow because the flow is important. 12:54 If you do not understand the flow, you're pretty much in trouble. 12:57 So this is taken off the Varnish website and it's, it's 13:00 three slides I have for you three, three kinds of flows. 13:04 So what happens here is that you, the 13:08 requests come in in a hook called VCL receive 13:10 and all these, all these little, balloon type 13:14 thingie, are hooks that you can hook into programatically. 13:17 So we'll be digging into code later. 13:20 And those aren't just clever names, those are important too. 13:22 VCL stands for Varnish Configuration Language, 13:24 and then, underscore and whatever it means. 13:27 So regv means receive, every request gets receive. 13:29 That's your point of entry. 13:32 And then there's decisions to make, red, green, yellow as you can see. 13:33 So if it's green, if it meets certain criteria, and 13:36 those were the criteria I mentioned here, some of the criteria. 13:40 It will look it up and will create a hash, and the hash is based on the URL. 13:45 And the host name, it will look it up in memory, and if 13:49 it finds it, you have a hit, if it doesn't, you have a miss. 13:51 If it doesn't meet those criteria, it will just pass. 13:54 You see the red line there? 13:56 Going directly to the back end? 13:57 And if it's something it doesn't understand, 13:59 it will bypass the engine completely and 14:01 create a pipe, a TCIP connection directly 14:03 to another system will completely ignore the cache. 14:07 If it's a hit you can still decide to pass it, 14:10 if it's a miss there's passing opportunities or you can fetch. 14:13 And fetching is connecting to Apache, connecting to IIS, connecting to 14:17 Engine X, connecting to whichever system you use that speaks HTTP. 14:20 And after the fetch, and that's page three, you can either deliver it, store 14:24 it in cache, or decide not to cache it and send it to the client. 14:29 Does that make sense? 14:33 It's like receiving, seeing if it's in 14:35 cache, or bypassing, fetching it, delivering it. 14:37 So far so good? 14:40 Everyone still with me? 14:41 Okay. 14:42 And this is a typical flow in v3. 14:42 And this is where the v3, v4 game starts. 14:45 You'll be seeing a lot of that. 14:49 If it's a hit, so if you request something and it is in cache and you don't 14:51 wanna connect to the backend but immediately deliver 14:56 it, this is the typical thing you'll be seeing. 14:58 You receive it, you look it up, it's a hit, you deliver it. 15:01 And those words, if I were you I would remember those, because those 15:05 will come back in the, in the syntax and the, and, and the coding. 15:08 If it's a miss, typically you will receive it, you look it 15:13 up, it'll be a miss, you will fetch it, and deliver it. 15:16 Now there are changes in v4. 15:19 Look. 15:20 See? 15:21 Changes. 15:21 Hash and look up have now been switched. 15:23 According to me, it makes much more sense, because looking up 15:28 is something you do after the hash has been made, right? 15:32 So if you create a hash first, then you look it up in memory. 15:34 So they, they did it right. 15:37 So first you receive it, then you hash it, it's a hit you deliver. 15:38 Otherwise, you receive it, you hash it, it's a miss 15:42 and see what they did here, and this is a 15:44 major feature of v4 in Varnish, they split up, the 15:46 request coming in and the backend connection in two separate trends. 15:50 This used to be one single trend, so that 15:54 caused a slow down for the person who got to 15:56 the cache and notice that it wasn't there, and it 16:00 needed to be fetched so that person had to wait. 16:02 And all the others got served stale data. 16:05 So now what happens is they break it up in two process or two treads. 16:07 Request comes in, fetch gets initiated, while that happens everyone gets all 16:10 data, no one has to wait and then the stuff gets in. 16:15 So they split that up in two methods. 16:18 The back end fetch and the back end response. 16:20 Whereas fetch in v3 was done after the fact. 16:22 So, after you have retrieved your data from the backend system, this happens. 16:25 And then eventually, you deliver. 16:30 And we have been talking an awful lot about 16:32 VCL, about the varnish configuration language, the tool we use. 16:34 Is that red readable for you people? 16:38 Yeah? 16:40 Somewhat? 16:40 And it's the main specific language, and I tend to call it curly braces style. 16:42 So for people who are familiar with PHP, Pearl, C#, C, 16:45 C++ this is something you'll understand and something you will appreciate. 16:48 It describes, as I mentioned before, request handling and caching polices. 16:53 And it get compiled so if you restart your 16:57 Varnish, it get compiled to C and is very optimized. 16:59 It's loaded as a shared object. 17:02 It has a bunch of hooks, as you noticed in the flow. 17:04 And there has been a syntax change that you are now aware of. 17:07 So those are the hooks, let's not spend to much time on this. 17:10 But just to show you that there's a tremendous amount of hooks. 17:13 And in these hooks you have behaviors, you have actions you can take. 17:17 So, if you receive a request, you could look it up. 17:20 And this is v3 stuff, you can look it up. 17:22 Pipe, pass or error. 17:24 Error is like exception showing that you do in your, in your programming language. 17:26 You just skip whatever you're doing and send data. 17:29 And then you can pipe, you can hash. 17:32 Let's not spend too much time on 17:34 this slide, these slides will be available online. 17:36 So if you wanna peek in later, be my guest. 17:38 In v4, see, I've added red. 17:41 There's a tremendous amount of changes. 17:43 The VCL backend response is now there instead of the fetch. 17:46 Instead of error we have now VCL sent. 17:51 What that means is like, if you wanna escape, if you wanna stop 17:54 your execution and want directly deliver HTTP output that is created in Varnish. 17:58 Let's say you have a 200, everything is fine, output 18:03 you wanna give to the, to the client, you do error. 18:06 But that's not really an error, 200, HDP200 code is 18:09 not an error code, it's, it's says that everything is okay. 18:12 So what they did is they changed that to synthetic output. 18:16 That's output created in Varnish, output that doesn't come from the bracket. 18:19 So they have a syn, VCL syn for that, and you can 18:22 directly purge, you have a purge hook where you can hook into. 18:25 But that would make sense. 18:28 This might sound like Chinese to you, if you're not Chinese, 18:30 this might sound Dutch to you, but we'll, we'll get there. 18:33 And finally, before we dig into the fun stuff, every VCL hook can 18:37 access certain objects, and you have four or five objects, you have a request. 18:43 That's what the client sends you. 18:47 You have a response in the end is what gets served to 18:49 the client, gets served back, and 18:53 everything in between depends on the behavior. 18:55 So if it gets stored in cache, we have the 18:57 object for it obj, if if it's not stored in 18:59 cache, you're gonna request it, and you will use the 19:02 backend request object, with all the proper fees that are there. 19:05 And if the backend responds, then its beresp backend response. 19:08 So, let's see some actual code, right? 19:12 The, I've been talking about default behavior and the flow. 19:15 This is the flow in action, okay. 19:18 Let's, let's go to this side for a minute, and go over it. 19:19 Is the print okay, can you read this in the back. 19:23 Is it. 19:26 Yeah? 19:26 Doable. 19:27 So, we received a request. 19:28 This is the hook where we dig into it. 19:30 If you don't specify any of this code, Varnish Retreat will behave like that. 19:32 This is behavior without even typing a single character. 19:36 But if we had to write it down, this is what it would look like. 19:39 So if there is no restart request, so if it just comes in for the first time, it's 19:42 gonna add a [UNKNOWN] foreheader so that your backend 19:47 application can retrieve the IP of the original request. 19:50 If it's not get, heads, put, post, trace, options or 19:53 delete, if it's just some sort of weird HTTP verb. 19:57 It will just wipe it off, and it will say I have no clue what you're talking 20:00 about, I will send this to the back end, and I'm not interested in what comes back. 20:04 If it's non-item quotient, it will pass it along to the back end, so if it's 20:09 not a get, or not a hit, we will pass, and pass means send it off. 20:15 This is criteria not met. 20:20 I don't wanna deal with this, I'm gonna send it back. 20:21 Same thing applies with authorization and cookie, user specific data. 20:25 Varnish doesn't wanna deal with that, sends 20:29 it back, and if all those criteria are 20:31 not met, we have a valid thing we can look up in the cache, return lookup. 20:33 Seems pretty simple, right? 20:37 If we can continue there is a piping mechanism that 20:39 doesn't do much but you can add logic to it. 20:42 Passing hook, that you can add logic to it, doesn't do much or anything special. 20:44 But, if you look at VCL hash. 20:50 This is how the hash is composed. 20:52 There is a hash data function that you use to create that hash. 20:53 And the first thing you do is, you add 20:57 your URL, because that's a clear identifier of a page. 20:58 But there could be multiple sites on a single server. 21:02 So you need a way of identifying the host. 21:04 If the host is set, use it, use request.htp.host. 21:06 See it as a request object in action. 21:10 And if it's not there, you use the server IP, because 21:13 you could just use an IP address to identify a page. 21:16 So that's that. 21:18 And it will return a hash tag that gets locked up in the cache. 21:19 If it's a hit you deliver it. 21:22 If it's a miss we'll fetch it from the back end. 21:23 And this is that fetching logic I've been talking about. 21:25 So if a TTL, so if a cache control header resulted in a time 21:28 to live less than zero or if there was set cookie, user specific data. 21:34 Something I haven't mentioned before. 21:40 Variation headers. 21:41 You can add cache variations if every single header 21:42 in your request is used for variation and it 21:45 doesn't really make sence, and we will, and this 21:48 is something, a new concept that I haven't explained before. 21:51 We're gonna head for pause. 21:54 So what that means is that we're going to store it in cache. 21:56 But as a sort of blacklist thing. 21:59 Because we have these mechanisms to determine 22:01 if it should be cacheable or not. 22:03 But if you store it in the hit for past cache, for 120 seconds as you 22:04 can see, the next 120 seconds we will make no decisions any more on future requests. 22:07 So that means that every time someone is. 22:12 Requesting that URL or, or, or, or that hash. 22:14 So combination of URL and host name, it will say don't store it. 22:18 Don't store it. 22:22 And that's a way of dealing with these kind of things. 22:23 And then you have your error which is synthetic output. 22:27 As you can see it's a place holder where variables go. 22:30 You can tweet that accordingly. 22:32 It always sends google mediation kinds of output. 22:34 Like its that's Farnish humor, but you change it to whatever you want it to be. 22:37 So it looks a little more branded you can 22:41 add your Cezzes and your java script to it. 22:43 Okay, so, what have we done so far? 22:46 We're half way to talk, I guess. 22:49 I hope I'm half way in terms of slides, too. 22:50 Yes? 22:53 We're looking good. 22:53 As we've set it up, we've configured it. 22:54 We know how it behaves. 22:56 We know what VCL look like, looks like. 22:58 And now we're gonna put it in production and see what happens. 23:00 And you have a nice set of tools. 23:02 That allow you to dig in and see what's happening. 23:05 Because no use in setting up a Varnish if you don't know what the response will be. 23:07 What the, what the behavior will look like and how effective it will be. 23:11 So first tool we're gonna use is 23:14 Varnishstat is a sort of continuously updated list 23:16 of parameters of your server, not request base 23:20 just the server, how is the server behaving? 23:23 And this is vTree stuff. 23:25 This is what it looks like in vTree. 23:26 You see your hit rate over the last ten 23:28 seconds, last 100 seconds, and the last 254 seconds. 23:29 That's because the, the screen was open for 254 seconds. 23:34 If I were to leave it open half an hour, it would be there. 23:37 And then you see all the kinds of action that you can do. 23:41 You see the share amount of connections coming in. 23:43 Or the amount of requests per seconds coming in. 23:46 You see the client requests, how much hits, how much 23:49 misses, back end connectivity because it can optimize the usage of 23:52 back end connections such as blah, blah, blah, blah and 23:56 then you can see, and that's an interesting one, end object. 23:59 That's the amount of object stored. 24:03 There's another one that is not visible right 24:04 here because the screen is not large enough. 24:06 It's a NLRU nuked and LRU stands for least recently used so if your 24:08 cache is full, if you have 1 gigabyte of caching memory and you have 2 gigabytes of 24:14 data that gets requested, let's say a lot of images, lots of, lots of video footage 24:18 that you, you want to be, you want to have stored, and if it gets full. 24:24 It drops the least recently used one, and if 24:27 that counter increases, you know you're running out of memory. 24:30 That could be a problem if you wanna serve all that data. 24:32 But if you have an entire stack of data and you just want 24:35 to serve the most popular things, you shouldn't worry too much about that. 24:38 Varnishstat has been optimized to v4. 24:42 This is what it looks like now, it's. 24:45 It looks a bit better I guess, but you don't see the hit rate anymore. 24:47 I read some mailing lists in for, some posts about this and 24:51 they say that the original, this one here, hit rate was a lie. 24:54 It was like an estimation. 24:58 It wasn't anything near close. 24:59 So this gives you an overview on what's happening 25:01 on our server, how much connections are we getting, 25:04 are there hits, are there misses, are we fetching 25:06 from the back end, and so on and so on. 25:08 Varnishlog. 25:10 That's where it gets really interesting. 25:10 It allows you to dig in and filter out specific requests coming in. 25:12 And I have to warn you, it's very verbose. 25:16 It doesn't get stored on disk, because if it 25:18 would've been stored on disk your disk would explode. 25:19 It gets stored in memory and you can hook into the memory and you can 25:22 look through whatever is there and it gets buffered and you can read that buffer. 25:26 If you run Varnish log on a production system, this will happen, but 25:31 it will be so fast that you won't be able to read it. 25:34 So it would be better to filter. 25:37 >> Boys have timed it up. 25:39 >> Yes! 25:40 [SOUND] Oh I'm sorry about that they have tied 25:40 it up thank you Ian for this very informative intermezzo. 25:43 okay, I feel, I feel better right now. 25:46 I feel a lot better they have tied it up who scored? 25:50 >> Just happened so I haven't seen it. 25:53 >> Okay we'll, we'll see that in a minute we'll hear about that in a minute. 25:55 so, as you can see,it's, it's very, very verbose, 25:59 and it allows you to see exactly is happening. 26:02 The first column is a sort of sequential number that 26:04 identifies the session, and then you can see the action happening. 26:07 So, we open a session, and your next column is either C 26:10 or B now, with C, it implies that these are client requests. 26:13 Request coming from the browser to the varnish, 26:16 and you can see we are connecting to 26:19 server 12121, this is a vm on my computer of course, and we're doing a get, we 26:21 are doing a rx kind of stuff, receiving kind of stuff, there you can see all the 26:27 headers coming in, and then you can see 26:31 vcl call, it receives it, you see, these verbs. 26:33 Or these keywords and hooks start coming useful. 26:37 You receive it, and all the criteria were 26:40 met, so there no cookies, no authorization headers. 26:43 It was a get, it was not a post. 26:46 So we'll look it up in cache, and it will create a hash as you can see, VCL call. 26:48 And then below you see the actual hash being built. 26:52 It was the homepage, so the slash. 26:55 And there was no host name. 26:57 I used the IP address, IP address was 26:58 used, we have our hash, but it wasn't stored 27:00 in cache, it was amiss, as you can see here, it was amiss, so we fetch it. 27:03 And if we fetch it, we're gonna use a back 27:07 end and that back end is going to be identified 27:09 by number 13, so if we go to one of 27:11 the next slides, you will see what happens in 13. 27:13 It's a clear tread. 27:16 You can follow and the back end is called default and in 27:17 the end, this is a kind of spoiler of what's about to happen. 27:20 RFC0TTO, so I didn't specify a cash control header that was bigger than zeo. 27:24 It was zero. 27:31 So, what it will do is it will fetch. 27:32 It will store it for 120 seconds according to the VCL. 27:35 So the VCL this side needs to be stored for 120 seconds. 27:38 Where? 27:41 In our hit for POD cache. 27:42 So it'll be blacklisted for the next 120 seconds. 27:44 And then we store that in an object and then we transmit that data to the user. 27:47 Pretty verbose right? 27:53 You can see a lot of stuff happening. 27:54 And then you can see 13 this is our back end request. 27:56 And as you see wait, wait, wait where does it happen? 28:00 Here? 28:04 Cache control no cache max H 0. 28:05 So if a client ask why isn't this page in cache you 28:07 want varnish log you dig in and you see exactly what is happening. 28:10 And these are the filtering options you can use. 28:14 So the minus C tells you only the filter on client interaction. 28:16 So that's connections coming into Varnish and 28:20 connections that Varnish sends back to the client. 28:22 You can use the minus M to filter on certain tags. 28:25 Tags are the second column. 28:28 And you can, make sure you filter out the hits or whatever you need to do. 28:30 There's more you can store these in files and append them to a binary file, 28:36 and that binary file could be used to replay or to look at later on. 28:39 Varnishlog in v4 looks pretty similar. 28:43 They've changed the way these things are named. 28:48 They've given him a clearer name, that is, is, makes much more sense. 28:52 But, and the sessions are, are, are, are separated much clearer. 28:57 But what's es, specifically spectacular about this tool in v4, 29:02 is that they now have a query language like SQL alike. 29:06 And it allows you to filter out tags. 29:10 And to because this was not possible in vTree. 29:13 So you wanna have all the urls of all the requests that have hits. 29:15 So you can see all the hits and all the misses. 29:20 Or you wanna make sure that you have all the pages only the 29:23 urls, where the fetch to the back end took longer than two seconds. 29:28 Very valuable information. 29:32 Or you can make sure that you have all the data. 29:34 Where the response header was, between 400, and 404, so, where the clients, 29:36 kind of screwed up, if you want to know, those kinds of things. 29:39 Varnishtop does the same thing. 29:43 But, it, does it, incrementally. 29:45 So, if we filter out, on the user agent you can see the top user agent. 29:47 And it's a mess, right? 29:50 Because there's so many variations of user agents. 29:51 And VarnishTop uses the similar syntax you can use minus i to get to filter 29:53 out tags minus capital I to do regular expression matches and so on, and so on. 29:59 In v4 it looks similar but using the minus Q 30:04 we have our nice little filtering language very powerful stuff. 30:07 Varnish NCSA is for those people who still want Apache style logs. 30:12 Because the apache of this, are gonna be empty once you have a good hit grade. 30:15 Because everything gonna be served, on the varnish, your apache is 30:19 not getting any hits so there's nothing in your access logs anymore. 30:22 But if you still want to replicate that behavior you can run Varnish NCSA as 30:25 a demon and these are the requests coming out, so very useful kind of stuff. 30:28 Who remembers that phrase, that popular phrase there 30:35 were only two things hard in IT, right? 30:37 Can anyone recite that? 30:40 One is what? 30:43 Naming things and two is? 30:44 'Kay, and there is a joke, there is only three things hard in computer science. 30:47 It's naming things,. 30:51 Cache purging and off by one error. 30:53 Yeah, kind of a stupid joke, but still. 30:57 You can purge and varnish and you can use the power of VCL to accomplish that. 30:59 So, as you can see, if you receive a request and its purged then look it up. 31:02 Why do you need to explicitly do that and return look up? 31:08 If you just let it continue. 31:11 It will drop into default behavior and default 31:12 behavior says if it's not gets put, whatever, it 31:15 will pipe it off and purge is not 31:18 really an official HTTP verb, it's something we invented. 31:19 So make sure to return immediately and look it up in the cache. 31:23 We look it up and again we filter our own purge. 31:27 And if it is there we. 31:30 Apply the purge message there and it will empty that specific page out 31:33 of the cache and will use synthetic output as you can see here. 31:38 To stop the execution until the user the client 31:41 that his has succeeded if it was a miss. 31:45 It was not in cache and you do a 404. 31:47 In V4 it just got a lot simpler this is V3. 31:51 This is v4 so if the method is purged return purge and there is a 31:55 separate hook that deals with all of this so very simple not a lot of logic. 31:58 To implement but varnish also have a every since V3 32:03 have a very powerful banning syntax so instead of just saying 32:07 we're gonna use a URL you can match on a lot 32:10 of things that are stored in the request for redirect objects. 32:13 So what you see here is, if the hosts equals our host 32:16 and the URL equals our URL, bannet, which is the same syntax. 32:20 But see what we do here. 32:25 We use a tilde, that does regular expression matching. 32:26 So if your request URL starts with something, then you can purge it. 32:29 And that means that you can. 32:35 Per jobs an entire tree. 32:36 Let's say you have a higher, higher tier structured website. 32:38 products, my products, product properties etcetera, etcetera. 32:42 It will purge it. 32:45 It will ban it immediately. 32:46 So, you have a lot of flexibility of 32:47 banning more than one page in that request. 32:49 In v4 they change things. 32:51 I'm gonna switch back and forward so you can see it. 32:52 They changed the syntax of. 32:55 Request, they named it to Method, which kind of makes sense. 32:57 And they use synthetic output instead of an error 33:02 because this is not an error, this is expected behavior. 33:04 So, 200 ban, that's basically it. 33:06 If you want to execute it, because that's where it gets useful, 33:12 you can hook that into your program and your logic of your software. 33:14 You can use curl or whatever other library you 33:18 sue to do HTTP requests from code and you can 33:21 just change the method to purge and it will purge 33:24 it like let's say you have a sort of hook 33:26 in your CMS where you have your delete or your 33:28 update or whatever you have and once you click it 33:31 it will update in the database and then in the 33:34 end it will trigger an HTTP call to your varnish. 33:36 To serve the fresh content. 33:38 That's something typical what you do when you have breaking news. 33:40 How long are you gonna cache something? 33:43 Infinitely. 33:44 It could be cached for days, weeks, months, years but 33:45 the moment that the update comes in, you wanna publish immediately. 33:47 And that's how you could do it. 33:50 A lot of people use the HTTP syntax with the purge method. 33:52 Other people use a telnet connection. 33:56 I use the binary here so if you, if you execute the binary it works as well. 33:58 So, varnish ADM is another binary and this is 34:03 just a wrapper around the telnet protocol that I 34:06 mentioned at the beginning of this thug, the minus 34:08 capital T which has a host in a port. 34:10 Well if you connect to it over telnet you can do the same things. 34:12 I've had a look at various CMS system like WordPress and Drupal, also Magento, like 34:16 popular CMS's and every single one of them implements it in, in, in a similar way. 34:21 And the dejupal plugin specifically allows you to choose between HTTP 34:27 or telnet, depending on the way you want to do it. 34:32 Like, if you want all the flexibility at your 34:34 software's end, like at your jupals end, you're going 34:36 to use the telnet, because you're free to type 34:39 in whatever you want, all the matching that you want. 34:40 If you want it to be easy and you don't want a lot of responsibility. 34:43 Just stick with that. 34:46 Purge security's important as well because everyone, like if 34:48 I'm clever and I know there's a varnish behind it 34:50 and I wanna be a punk, I just go to 34:53 every single site and purge it, purge, purge, purge purge. 34:55 Every single URL and the website will go down in minutes. 34:58 So you don't want that. 35:00 You want security, you want added security. 35:01 So what you do then is define an ACL, and that ACL, you can match it here. 35:03 If the client's IP is not in the list of IPs, subnets, host names, don't allow it. 35:09 Do an error, 405 no allow it. 35:16 In v4 we're going to use the syn C syntax, and 35:19 we're going to use the purge method here and a work. 35:22 Just fine. 35:25 Okay, quick infomezzo. 35:26 I have officially ten minutes left, but I'm gonna skip the Q&A. 35:27 I'm gonna use that for extra content, if you don't mind. 35:31 It does load balancing too. 35:34 Im gonna show you that pretty picture again. 35:35 It does load balancing to Varnish, and it distributes loads either 35:38 across the back ends or could be used as fail over strategy. 35:42 And for that it uses a term called Directors. 35:45 And Directors. 35:48 Yes? 35:49 Got up to 2 1. 35:51 >> Whoa, that's huge. 35:51 Thank you Ian, you made my day. 35:53 That's so nice. 35:56 I, I didn't expect them to know. 35:57 So my initial plan was to shut down all 35:58 social media, shut down every notification system I had, 36:01 and find a way to look at, like, pause the game on my iPad and just, it doesn't work. 36:04 So I'm very grateful, Ian. 36:09 That being said. 36:11 Directors are, behave like a back end, but they group several back ends within. 36:13 And you have several strategies of doing it. 36:18 You can do your typical round robin, the one 36:20 two, one two, just sequencing around your back ends. 36:22 Or you can use a random strategy. 36:26 Or you could do client hashing, which is a very interesting way of doing this. 36:28 Let's say you use sessions in your code, but the sessions get stored on this. 36:31 And if you load balance and you com, you, you get to reach another server, and 36:35 that one doesn't have your session on it, 36:38 you're shopping cart will just pff, be blank. 36:40 So in those cases if you don't do session clustering, you want 36:42 to use sticky IP as they call it, and this is sticky IP. 36:46 It will check your IP and will only route you to that very specific server. 36:49 The hash. 36:54 Is based on the URL, so, it will use URLs and distribute it evenly. 36:55 Every URL goes to a unique back end. 36:59 And you can use fallback. 37:02 You just stack several varnishes, and use them in priority. 37:03 DNS, look it up if you're interested. 37:08 It's too complicated. 37:10 I don't understand how it works. 37:11 We use health probes to define if a back end is healthy or not, 37:13 and you can specify all the parameters, 37:18 how much you should check, how many failures 37:20 before your back end is considered unhealthy, 37:23 how many successful pings should it have to 37:25 consider it healthy again, the expected responds, you can even add raw http to it. 37:29 For, for these purposes. 37:35 And I didn't mention this before, but you can, you can 37:36 add an extra parameter probe and link it, or do this inline. 37:39 And you're back end will, have these checks and that's 37:43 ideal to determine if a back end is helped or not. 37:46 And this especially important when you do fallback. 37:48 This is round robin, so you have your two back ends,. 37:51 One and two. 37:55 And you have your directory that behaves as a back hand. 37:55 An that is named local hosts. 37:59 And we use a round robin strategy. 38:01 We have back hand one and back hand two. 38:02 But just for the fun of it I show you that 38:04 there is a way of adding a third host in line. 38:06 And the only thing you do is set it here and you have a round robin load balancing. 38:10 See what changes here, not much right? 38:16 If you use random, we just change a keyword random, you can add weights to it. 38:18 Lets say you have a, a less reliable server you gonna send it best traffic. 38:22 Fallback, as I mentioned use health probes. 38:27 They are important, otherwise you're varnish won't be able 38:29 to determine if a system is healthy or not. 38:32 And order matters, so the first one is gonna get selected first. 38:35 If the first one drops. 38:38 Second one is gonna be used. 38:40 IP hash very simple, and it uses a client identity. 38:42 I've set this, just to show you, if you 38:45 don't set it it will still use the client IP. 38:47 And this is sticky IP in action. 38:49 If you don't want the IP to be the identifier, you can 38:51 add whatever you want here, and this will be used to distribute evenly. 38:54 URL hash. 38:58 Uses in the same way, but no extra parameters need to be mentions. 39:00 You can add weights to and it will distribute evenly using your URL. 39:03 And the URL, this is something, that can be kind of useful. 39:09 This is a, I don't really have time for intermezzo's but I"ll show you that. 39:12 Lets say that you have 1 gigabyte. 39:16 Of memory. 39:19 And you have 10 gigabytes of data and you want all of that stuff to be in cash. 39:20 One Varnish is not going to do it. 39:25 So what you can do is have a bottom 39:26 layer of Varnishes that you can use for horizontal distribution. 39:27 Distributed computing, right Aaron? 39:31 Distributed. 39:32 And you can store all your stuff on there, let's say you have a lot of 39:34 images, you'll store it and you put an 39:37 extra layer of Varnish on top of it [INAUDIBLE] 39:39 distribution that will send every URL for every 39:41 request, like every resource to a specific server, that 39:46 way you can spread it evenly and this one will be very fast and will be tuned. 39:49 To serve the most popular data. 39:53 And this will be tuned to surf all data so, 39:54 this will be stored here and this will be stored there. 39:57 You're not forced to Varnish as your top layer. 40:00 Any reverse proxy will do. 40:02 You can use Engine X, or, or whatever you wanna use. 40:03 But this is, an excellent strategy if you have more, you have, if 40:06 you don't have enough ram, and you have, a boat load of data. 40:10 So I hear the question already. 40:14 What about v4, how do you do loadbalancing in v4. 40:16 Well directors are no longer there in the core, they moved 40:18 them away, and created what they call vmods, va, varnish modules. 40:21 And these are C. 40:25 Modules that are available in the system or on GitHub. 40:26 There is a community out there and what you 40:30 do here is, you, every varnish before starts with v4. 40:32 It doesn't mean that if you mention, if you 40:37 don't specify this feature here feature is no longer compatible. 40:38 You mentioned v4 you imported the directories and in your in 40:43 it you'll do a bit of like seal like magic you're gonna. 40:46 Instead of using all the hooks, you will actually do a bit of programming. 40:50 You will initialize a new a, a new director, a virtual 40:53 director, and add your Apache and your Engine X back end, and 40:56 the only thing you need to do instead of [UNKNOWN] back 41:00 end, [INAUDIBLE] back end to video back end, and it will work. 41:03 Slight change, it, it seems that the impact is big on your VCL. 41:06 But I find it to be quite interesting and I find this 41:11 to be the way forward, randomization, see not much changing, just change the 41:13 innards from round robin to random, adds the weights, fallback, you 41:19 do the same thing so not much changes, add your probes that you've defined elsewhere. 41:25 IP hashing is no longer done separately, it's just hash and you just 41:30 mention what you want to hash here, out here, and you say client identity 41:35 or request IP or whatever you want it to be and for C 41:40 nothing changes actually if you wanted to be distributed using the URL, user URL. 41:45 Plain and simple, they narrowed it down. 41:50 So last minutes. 41:53 Let's show you the power of VCL and do some very useful things. 41:55 Let's say your application you're does not support cache 42:00 control headers or you've not been disciplined in that way. 42:03 And it's a mess and you don't have any control of 42:07 how long things are gonna get cache from the application level. 42:10 Luckily you can use your VCL fetch logic and say if the URL that I'm fetching. 42:12 Starts with Blah, so blah1, blah2 is match 42:17 two, fairly logical names for URLs of course. 42:20 You can set the back end response DTL, you can over-ride 42:25 it to 10 seconds, in all our cases, use an hour. 42:28 In v4 it changes a bit because the requests you see 42:33 here, we don't use reg, we use dereg, so the back-end requests. 42:36 Is the one we should use now and the fetch has been renamed to back end response. 42:40 Other things. 42:46 Removing cookies. 42:47 Let's say cookies get generated on the 42:47 system and you don't need them for anything. 42:49 Just remove them that way. 42:51 Unset the cookie and or when the cookie comes 42:53 in from the back end instead of this way. 42:55 I've done this number of times. 42:57 In v4 the only that changes is the methods. 42:59 This is something you should have in every single varnish configuration you use. 43:01 Who uses Google Analytics? 43:06 Everyone, right? 43:07 Google Analytics. 43:08 There are people who don't use Google Analytics, wow! 43:09 Spectacular. 43:12 So Google Analytics is just a piece of JavaScript 43:13 you include and what it does, it starts setting cookies. 43:17 Those UTM style cookies, and these are very annoying. 43:20 But you should know that your server itself, your Apache, 43:23 or IIS, or whatever you're using, does not look at these. 43:26 This is just interaction between JavaScript and your local cookie store. 43:30 So, if you just drop them, nothing will happen to your Google 43:33 Analytics results, but it will make sure that you can actually catch things. 43:36 So, on setting, that way, you can use regular expression magic to match those. 43:40 And if, in the end, after you've removed all those 43:45 cookies, it's just an empty screen, just drop the cookie entirely. 43:46 Or you can hash a cookie. 43:50 That's interesting. 43:51 A lot of people use try to specify languages or 43:52 region, lo, location, based on a splash page, you know, right? 43:55 You enter a splash page, you see a map of the world. 43:58 And you have to select your region or your language. 44:00 Not a lot of people do that using the URL or using the header for that. 44:03 Like the language header that is there they accept language. 44:06 They use it using a cookie so if you don't 44:09 take care of that cookie the site will not work. 44:11 And depending on the first hit let's say you have three languages on your 44:13 website or ten languages and the first one is a Frenchies and he goes there. 44:16 Every English guy will see the french language. 44:20 So that's not something you would like I guess so what you do here. 44:22 It's in the hashing, if you, if the cookie contains it's 44:26 a tilde, if it contains a language cookie; extract that language. 44:29 And hash it, hash it accordingly. 44:36 So what you do is you have your URL, your host 44:38 and in additionally you have a variation based on that language cookie. 44:41 And so you have Deutsch. 44:44 An English, a German, an Italian, and that way you can spread it. 44:45 And you can use actually the power of cookies 44:48 to not break your website and make sure it 44:51 still works.Cacheing static files, once a cookie is being 44:53 set, it gets set for everything, even for images. 44:56 So, this is a default you should add to your VCL's as well. 44:59 Remove your cookies if it is anything like this. 45:03 Look it up in cache. 45:05 And in v4 it changes a bit, this is one I use when I start working on 45:07 a, on a varnish assignment to, to see if it, if it's a hit or not, I add 45:12 an extra header an xheader because that's what 45:16 you're allowed to do if you're, you adding extra 45:18 headers you can't name it whatever you want, It 45:21 should be named very specifically, a hit or miss. 45:23 Final. 45:27 Do I have five minutes more? 45:28 Can I get five more minutes of your attention, please? 45:30 Score still the same? 45:33 Etch side includes. 45:35 Anyone heard of etch side includes? 45:36 Do you like etch side includes? 45:39 Stumps. 45:40 Okay. 45:41 People like it, so you should use it if possible. 45:42 It's actually adding pieces to the puzzle, as this image shows you. 45:45 Imagine this set up. 45:48 I'm a PHP guy, I'm sorry for that you can throw stones, rocks at me 45:50 for whatever reason, but this is something you will see in a lot of cases. 45:54 Your typical page layout, a header. 45:58 A footer, a menu, and your main page for all the content list. 46:00 A header will usually contain welcome Peter 46:04 or welcome Stephanie or welcome whoever, so 46:07 that's all going to ge cached because you are going to use cookies for that, 46:10 or you're going to use specific things to take care of that, so let's say 46:13 we don't want caching here and our menu can only be cached for ten seconds. 46:16 On our main page for two seconds and our header for five seconds. 46:20 You kind of do this in Varnish because a 46:24 page is a single request and it has one TTL. 46:25 But, it is possible and I'll show you the trick. 46:29 Let's say we use this HTML. 46:32 I still use tables, I know, this is just 46:33 for the purpose of showing you how this works. 46:36 And we load these various. 46:38 Blocks of content. 46:41 But what if, see how we change it, what if we can use 46:42 these kind of tags, ESI tags, which are official, they are in the 46:46 W3C spec and you load them there, and Varnish can understand ESI, and 46:49 will render these pages separately, so will, will open up a set of requests. 46:54 Get all the data, respect that specific TTL, so if you say I want 47:00 that page 10 seconds, that one 5 minutes, that one 1 hour, that one 47:04 infinitely, it will respect that and it will pass it along as a single 47:06 document, so that is hugely powerful, because 47:11 if you don't want caching on your header. 47:13 The minimum TTL is the one of the, the least cacheable. 47:16 So if you have something you can cache for an hour and something you 47:19 can cache for a second, you will always take that one for a second. 47:21 But now you don't have to make that trade off anymore. 47:25 You can use it that in that way. 47:27 And this is how you do it in ESI. 47:28 You add an extra header or you can do it 47:31 explicitly under URL basis, but there is a standard for it. 47:33 There is an official header called the surrogate capability header. 47:36 And if you say in the key that ESI supported, your back end, your Apache, 47:39 your IIS, your EngineNext will know that 47:43 the system that is sending this supports ESI. 47:47 So in your PHP, your Python, your Ruby, whatever you're 47:50 using, your NodeJS, it's gonna know like okay, the system in 47:53 front of me supports ESI, so instead of loading it 47:56 as a single page, I can just put the tags there. 47:59 And Varnish will take care of it. 48:02 And once it comes back and your application 48:03 sends a surrogate control header, it's a sort of 48:06 confirmation like, okay, so that system that I 48:08 exposed ESI to, it now understands ESI as well. 48:11 And it sends ESI and just you, ESI. 48:14 It's just a matter of reading the capability header and sending back the. 48:17 Control header and you're doing fine. 48:22 In v4 it only changes the back end response and you're good to go. 48:24 Ending. 48:28 This is the final part. 48:29 Remember Varnish does not support SSL. 48:30 It's a political thing, they don't want SSL, so terminated elsewhere 48:33 you can put an Engine X in front of, or a pound, 48:37 or a h, a proxy, put something in front of your varnish 48:39 if you're using SSL because Varnish is not gonna deal with it. 48:43 And to end this very nice session, thank 48:46 you for being here, what about your projects? 48:51 Think about it. 48:54 If you're considering using Varnish and you have something custom 48:55 tailored like, not something CMS will like, think about your URLs. 48:59 What are the URL patterns that we're using? 49:02 Is there anything that is not cache-able? 49:05 What about cookies? 49:07 Am I using cookies? 49:08 Can I use certain cookies to do cash variation? 49:09 Should I drop certain cookies? 49:12 Are there pages that will still use cookies and that are not cache-able. 49:14 Think about these things very throughly if you're starting a new project. 49:18 Think about these things from the get go because if that is in your 49:23 architecture, it's just a matter of putting 49:25 varnish in front of it and it'll work. 49:27 And with that, I'll like to send you to 49:29 the break because there is a break right now. 49:32 I am very grateful for you being here. 49:34 I'm grateful that Ian kept me up to date on the score. 49:35 And thank you. 49:38