All right, how's everybody doing today? All right, everybody full of food? All right, everybody here is OK? Cool, awesome. All right, so hopefully you're here for basically a full-stack cash dive. This is a two-hour lab, so this is a very hands-on event. We're going to be handing out USB sticks. If you don't have a USB port in your computer, let us know. We have DVDs as well. Hopefully you have a DVD drive. We've done this talk, I think, now three times or so. So this is supposed to be very interactive. We want you guys to ask questions. We want you guys to interrupt us. We want you to do, if you have questions, raise your hand. One of us will come out and try to work with you. We broke this up into three different sections. I'm basically going to start by doing a basic introduction of what we're talking about. Also, I'm Jason Ford, CTO of Blackmash. Campbell is with Form 1. And Ernest is with the Economist.  If you don't want to do that, that's OK. You can follow along on the screen with us. And then from there, Campbell, I think, is going to go second with basically diving into some varnished stuff and talking about how to make the site on this VM that we give you run faster. So you're going to be actively working inside this VM and hopefully breaking it and then fixing it. And there's going to be certain things that you're not probably going to understand, which is good. That's what we want to have to happen. And then we're going to help you get through those. And then on the last part, we're going to basically go into a really deep dive on different methods and styles of how to troubleshoot different caching problems you may have. Maybe a site's not caching at all, or maybe it's taking too long to load or something like that. So we've structured this so that we can adapt depending on the knowledge level that you guys have going into this. So the only way that works is if you are brave enough to raise your hands and let us know when we say something that makes no sense or something that, does that mean that makes no sense? Oh, no, you're just fixing your hair. But good, I like the way you're working. This is going to be very helpful for us. Yeah, so that's the only way it works. Halfway through, we're going to take a little breather so everyone can get up and move around and wake up a little bit. And yeah, please do talk back and let us know what you understand and what you don't. So right now you've got, yep, I'm back. Yeah, so on these USBs and these DVDs that are being handed out right now, I'm actually going to go through that process on my slide on how to get that VM off of there. There is VirtualBox installers for Windows and OS X on there. If you're running Linux, then the problem is there's 14 different Linux versions for VirtualBox. So just go and Google VirtualBox and go download the right one for you. Unfortunately, I couldn't fit them all onto there because it's just a lot of stuff. So anybody, any other questions before we get started? Yes? Yes. Three. Yeah, three, yeah. Good question. Yes, excellent question. All right, cool. All right, so to get started. Like I said, Campbell, Ernest and I kind of just give our contact information. Feel free to email us after this if you wish. Find us, seek us out. We're running around. We are happy to answer questions. If you have problems, if I don't know the answer, if Campbell doesn't know the answer, if Ernest doesn't know the answer, we probably know someone who does. And we're always intrigued to find new things that are out there that we haven't seen before as well. So just a quick survey in the room who here has done varnish or any kind of caching stuff? Awesome. That is what I was hoping. How many of you have played with Vickle and VCL stuff before? Understand Fetch and stuff like that? Awesome, good, good, awesome. How many people have set up APC memcached? Awesome. I'm very happy. This is much better than the last one we did. It was like three people out of 150 raised their hand. We're like, oh, that's not good. So kind of go over some of the architectures, kind of the overview. We're going to go over some of the architecture stuff that we have inside of this and why we designed it this way. We've tried to mimic a production stack of things that we see on a regular basis and try to mirror that as best we can into a local environment. Kind of go over some of the overview of those technologies, each of those things, whether it's Apache or why we use Apache or why we would use Nginx or why you'd use varnish or something else or what, those different choices you need to make in those different processes. And some of the experiences that all three of us have hit throughout these years with playing with this stuff. Then we're going to basically install this virtual instance locally on your machine. And then from there, it's basically going to be cash, cash, cash is what we're going to do. We're going to try to break some stuff, make some things fixed, take stuff that's loading in really long times, minute plus load times, down to instantaneously loading. Basically building some basic vehicles, some troubleshooting techniques, things that you may have not done or thought about, how to basically pull those things together. If you don't get a USB or a DVD, we've given out all the USBs. So ask your neighbor for one or raise your hand if you don't have one. And Dan will find you. Ooh, thanks. I knew 100 wasn't enough. So if you can just pass them. Just pass them down. Cool. Cool. Just make sure you share. We are a friendly community, we share. Yeah, and some basic varnish examples and basic troubleshooting. Make sure you copy all the files off those USB sticks. There are some samples on there as well that we've kind of used and just as a starting place. So kind of get over some of this. This is going to be repetitive for some of you. So kind of the full stack of Drupal, right? So different ways of caching, different levels. And you want to do caching in layers. So a lot of times what you'll find yourself using is either an Akamai or LimeLight or a Max CDN or something along those lines as being your front-end line of defense against large spikes of traffic. So those things can protect you from getting DDoS even if someone's trying to be malicious on your site or just trying to get out closer to your user base. So executing things like CloudFront from Amazon or using Max CDN, which are pretty cost-effective solutions. Or if you need something that's a little more enterprise level, you can go with a LimeLight or an Akamai or something like that, but you pay for those services. But it does protect you, right? So it gives you that first line of defense against not only security, but also against other things that traffic spikes that are hitting you. So the next level down from that typically on architecture is some kind of SSL offload because at the end of the day, Varnish doesn't speak SSL. So you have to get it out of talking SSL encrypted stuff. So how do you do that, right? So there's about six different ways of three different ways to do that. One way is using Pound. That was kind of the old school way of most people doing it. You can use an actual hardware load balancer, whether that's a Chem Technologies or an F5 or something like that, if you have the ability to buy those things. Most of the time we don't because we're in a cloud environment. So you have to make do with what you got. HA Proxy's latest rev version Dev actually has SSL support in it now. So if you're at HA Proxy aware and you know how to configure those things, you can offload there. You can use an Apache Proxy or an Nginx Proxy in front, which is a pretty popular way of doing it as well. Something to get SSL offloaded, right? Because SSL will not ever be cached for anything you're doing. Once it comes out of that Proxy or that setting, you're basically gonna drop it into some, mostly a load balancing technology, whether it's Varnish you're using that as a load balancer or Nginx or IPVS and a kernel or HA Proxy. Again, you can have multiple layers or do it on one layer. And then Varnish is a cache layer itself. Yeah, it does not. Yeah, like I said, I couldn't, there's 14 different versions of VirtualBox for Linux, depending upon your kernel version and your OS. So just download it, hopefully the Wi-Fi will hold up. It's not huge, it's like 100 megs, so. So, yep. It is. That is just a VirtualBox program installed. Yeah, no, no, that's inside. We'll get to that in a second. It's also a virtual machine on that disk, but it's not in the same folder. Yeah. The Varnish 101? It is. Yeah. So, yep. Sadly, it's four gigs in size, or two gigs in size. So it's a little, I didn't wanna kill the Wi-Fi, which we all know, a DrupalCon Wi-Fi is sometimes rough. So, by the time I get to those slides, you should be able to have a USB and a DVD in your hand, would be my guess. Could it be work? Yep. So, the next level is basically Varnishes, as you know already today with all the hands that are up. You guys sort of know about that already, and we're gonna dive into that pretty heavily today. And then, web server technology, whether it's Apache, Nginx, Lighty, depend upon what you're actually doing, right? So, there's a holy war that could be waged between Apache and Nginx. Everybody has one, sort of like the Emacs and VI. Which one do you use, and how do you use those things? It's your choice. There's not really a lot of differences between the two, except for memory footprint. And if you're in smaller VMs and things of that nature in Amazon you have to deal with, then Nginx makes sense, right? But you're loading PHP outside of the program and calling it separately.  So, just a little more efficient. In our opinion, it's Apache is more efficient than Nginx, from the perspective of just ease of use and configurability. But again, you have to deal with what you got. So, high availability solutions, kind of whatever that already, you know, basically you can have multiple things horizontally scaled in these solutions. Whether you're doing the offload, you can use heartbeat or something between those. Same thing in the varnish layers, you can load bounce varnish. Same thing in the Apache side. You just have to make sure persistence is set. In some cases, because, you know, when you log into Drupal, it sets certain things and you want to make sure those things get carried down to the right web head. Again, cache on layers is the biggest message we need to say here. Anybody have any questions so far? Good? Yeah. Yeah. Yeah, absolutely. Yeah, we're gonna make these available afterwards. Yeah. So, kind of the lab stack we're giving you on this medium that we're handing out right now. So, obviously you need your laptop. That's the number one thing. Can't use iPads. Can't use, someone actually said in Prague, like he showed me a Windows 95 box and said, can you install VirtualBox on this? And I'm like, no, please no. If you have 32-bit operating system installed, this will also not work. It is a 64-bit VM. So, that's another problem. The installer for VirtualBox is on that medium. So, basically if you haven't installed it yet or you don't have it, please install it. And I'll get to that in a few slides. It is sent off 6.5, 64-bit. Varnish, of course, is why we're here, APC, Memcache, MySQL. So, Varnish is just the first level of defense, right? If you're not using CDN, which most people don't, that's gonna be your first level. There's lots of things Varnish can do for you besides caching. You can put mod security rules inside Varnish where you can actually do, basically IDP rules to filter out people from doing cross-site scripting hacks, SQL injection, things of that nature. If you have that problem, I highly encourage you to go look at those things. Those Vickles are out there. They're in the wild. They're on GitHub. They're very useful, especially if you're trying to do some kind of PCI compliance where you need a WAF web application firewall, it can actually meet those needs. So, Varnish is a really useful tool, right? It's universal as well. Ernest is gonna go over some stuff using some conceptual knowledge of how Varnish can be used in ways that you wouldn't think of. And that's kind of the good part of this is that each of us have kind of a different perspective on how these things work and how they work together. So Apache for us, in this case, just because that's what we're familiar with, that's what we work with a lot, we don't have memory limitations. So, Nginx is really, like I said, is whenever you have limited memory to deal with and you wanna have concurrency hit, you can typically hit more concurrency on Nginx, but that's what horizontal scaling is for in load bouncing if you need to go more. Wait a minute, nobody put up their hands for the fact that we're using Apache and not Nginx? I like this. Is it nobody who wants to argue this? Let's hear your argument. Give him hell. What's the reason you'd use Nginx over Apache? Okay. So, the statement was I'm having horrible performance issues of Apache, so Nginx is the way to go. So, that is, in a lot of cases, there's situations where, like I said, your memory's starved, so Apache is the problem, right? So, if you're trying to do, whenever your Apache Trotter can go to 256 mags of memory and now you have 15 or 20 of them running around, that chews up a lot of space, right? And that's an issue. If you use Nginx with the fast CGI side, or FPM, basically you can limit those things from happening. However, typically it's not usually Apache's fault. It's usually something else that is causing it. Usually it's PHP, or it's something else that's outside of that's impacting it. Apache at the end of the day is just a web server, so it's just doing what it's told to do. So the biggest thing is, what I would suggest is make sure you go and look at logs and figuring out what is making Apache do that, or what Nginx is doing that. Generally, most of the time, just switching them out is not gonna solve the issue. Sometimes it does. The biggest use of memory is gonna be coming from the PHP application in the first place, and whether you're loading that from Apache or you're loading that from Nginx, you're loading the same library and you're interpreting the same script. A high memory usage script, like Drupal 7 under certain configurations, is gonna be high memory usage under Nginx, Apache, Lighty, whatever you want. Got another one. Sure. And that's definitely a really valid reason to pick. So the comment was that in his particular shop, they use Nginx partly because they find the configuration management a lot easier for their administrative overhead. They're more comfortable with it. All the configuration is in the same place. That is totally valid, and those are good reasons to use Nginx. I would say in defense of Apache that you can get great performance gains if you take everything out of HD access, disable HD access reading and dump all those rules into a configuration file, the same way you have to do with Nginx. But in the end, the most important thing is you should use the tool that you're most comfortable with. Right, exactly. And that's, you know, at most of our cases, we're running into situations where we're given what we're given and that's what the developer's like or something along those lines. So, you know, you have to choose the tool that you know how to use and you also have to use the tool that you know, right? If you don't know something, you don't know how to use that tool and you know how to make something else scale and by all means, use that. Not everything is a nail, but a lot of things can be nails. You're good with a hammer. Exactly. So, with PHP, you know, this is 5.3 and I'll say this out loud here as it gets on recording is 5.3 is now, I believe, end of life. So, 5.4 and 5.5 are kind of the way to go these days. 5.2 is definitely end of life. It's been that way for a while. So from a security perspective, you know, if you guys have 5.3 out there, start looking at ways of getting 5.4 into your environments. That's my security hat, sorry. So in this case, we are using 5.3. Sorry to say that. But we have an APC as a cache level as well for PHP. Who here has dealt with APC in the past? Awesome, awesome, good, good. Other than, have you ever used it, other than using it for PHP bytecode compiling? It is a caching, it's a binary cache. Yeah, object cache. No, not that I'm aware of, no. Question was, is there an issue with APC and 5.4? Not that I'm aware of. I mean, we're running it in certain sites, so. Okay, yep, in the back. That's true, 5.5 I know is definitely has an issue. Yeah, it's been basically the code from APC has moved to OpCache. It does the same thing and works in very, very nearly identically the same way. And in fact, as far as Drupal users are concerned, it is totally identical in swap out. But that's actually a very good point. You mean like in your apc.ini file? I think so, yeah. At least the ones that I use, there may be some really in-depth stuff that's changed, but. Yeah, I think the shared memory stuff and all that stuff is still the same time to live. The important bits that we're always changing. The question is, what about progress in file uploads? That I don't think is actually related, it works. I haven't seen any issue with it anyway. All right, so continuing on. So we use memcache for this. We certainly could use Redis, but memcache in this particular case, mainly because we didn't have time to put Redis into this. But you can certainly use that. They have, each of them have their strengths. Redis is a little bit faster. I think it's a little less complex. But at the same time, memcache has kind of tried true and tested. So if you're familiar with one or the other, again, choose the right tool for the right thing. MySQL is on this particular piece for us. You can certainly use MariaDB. They're pretty much interchangeable. So we've used them both. They both have their strengths again and their weaknesses. MariaDB has a lot of the enterprise features that MySQL you don't get unless you buy enterprise. So if you're looking for those particular features, which are pretty slim, most people don't need them. It is their, NODB performance is a little bit higher in Maria, in our test cases anyway. So again, it is use what you, the performance increase isn't enough to make you wanna just rip it out and replace it. And that's kind of the point we're trying to get here is that get the low hanging fruit, find the stuff that you can take out easily, and then replace those pieces or configure those pieces. I kind of want to remost this already. Yep. If everybody has an error on zipping the varnish file, this is gonna be a very tricky session. I'm gonna be uploading that to a Dropbox and we're all gonna crush the Wi-Fi. Thank you. Oh, you have Linux. So I zipped it on a Mac. So if that's a problem, yeah, use Unzip. Okay, cool. So use Unzip for Linux people. Awesome. So Connery went over the memcache, redis, keystore, idea, just more optimization things and more than anything else. If you're not using a module, don't use it.  Just remove it. If you're not using a module and Drupal, turn it off. The bigger part is that if you don't turn it off, then that's just more stuff that PHP's gonna have to do and you have more hooks to call and causes more overhead and just causes all kinds of pain and suffering when you try to do upgrades and things can break and white screen and you won't know why. It seems like a really minor thing to uncheck that little module box, but it actually can make an enormous difference. Is that a question over there? Oh, I always forget which one is which. The question is, do we have a preference for the Pekal memcache modules? Memcache storage versus memcache. Do you have a preference? Why can't I remember? One of them is maintained better, but I never remember which. Yeah, I actually use the Pekal module. I mean, we usually just use the Pekal module and that's it. Yeah. At the Drupal level, that's you. At the Drupal level. If there's a separate memcache storage module, I have never heard of it before, but I will look at it right now and get back to you. Thank you. Yeah, again, this is a lab, so we're learning to as everyone is. So there's certain things that you can only be exposed to so much. So everybody has a different experience and that's the cool part about these labs that we've done in the past is everybody has something that's different, so that's why we want you to speak up. So back in the back. I'm sorry, are you gonna have to use either a microphone or just talk a lot louder? Okay, so the comment was that he thinks cash router is not being maintained right now and that memcache module is the one that's being maintained. Okay, so that's definitely out. Okay, cash router is 6x. Sorry, but is it being maintained for 6x? Okay, a lot of cash router ended up in core for 7x. So, God help you if you're still using Drupal 6x, but if you are, please use PressFlow. Please, for the love of God, use PressFlow because varnish isn't supported in D6 by default. So if you have a D6 site, upgrade it. It is my biggest thing. And you'd be surprised how many people are still running D5. There's a lot of it out there, unfortunately. So just try to use the tools that are out there to kind of make things scale. D6 was a great first effort. PressFlow is even a better effort. D7 is even better. I'm sure D8 will be the same way.  As you probably already know, just more of a point of optimization. Use solar, get it outside. Do, it's much more robust. It works a lot easier. I'm not sure about D8 search. I'm sure that there's people in this room are much better versed in that than I am or anyone else up here is. But at the end of the day, use solar, use something else, lose ring, something to get that stuff out. The question was, what about views-level caching, panels-level caching, that's gonna be covered in my part. What Jason is talking about is the various back-end technologies that we have as options. But we'll definitely be talking about some of those other internal-to-drupal cache layers. Right, right. So the question was, is Google Appliance for the site and then outside of Google Appliance are using just regular search for the rest of the site? Is that killing performance? It depends what features that you're trying to use. Generally, what we say is that search is not great in Drupal. That's why solar is out there, it's why other things are out there. Much like you wouldn't put all those documents in Drupal search, you have a Google Appliance for that. So it's providing a certain- Public site, that's the front end. Okay. Now I'm talking about my content providers who would be using native search. They're the only group. It's the same concept, right? So you're outsourcing that search into something else. The short answer is that, yes, solar is much more lightweight than the Drupal search engine, and more accurate, if only because the data storage model is a lot simpler. So kind of go just quickly through my SQL because I'm running out of time in the sections I gotta do the intro, because I wanna get your VMs booted up. So master, master replication, if you're doing HA, there's something out there called Tungsten Replicator, I think it's Google, has that in their code repository. There's also a commercial product for that as well. Highly encourage you to look at that if you're trying to do master, master in several sites. It is a pretty good product. We've tried to use it a couple of places and it's worked. Rewriting proxies, stay away from them. Don't do it.  Trying to break reads and writes out in my SQL and a proxy is just asking for death. Just do master, master. It's much easier. Last question. Yep. How do you use it? Do you want to go back and look at it? Yeah, yeah. Probably not gonna remember that. Yeah, I can do that. How about whenever I upload it, I'll change it for you. That's, yeah, absolutely. And hopefully this audio is gonna be there too, so you'll be able to hear that because it is being recorded.  Delayed reads, slaves for my SQL if you're not doing master, master or delayed. So if you're doing something with comments or something like that, make sure you take that into consideration. You can do reporting only slaves on your data. So break that stuff out. The important bit is to break stuff out so you can get those pieces separated. Again, there's so many things that we could talk about here. Query cache turning off. I mean, I could go for hours on my SQL alone, which that's not why we're here. So getting the thing that we handed out to boot. So install VirtualBox if you haven't already from the VirtualBox directory. Most of you probably haven't installed from using other tools. Copy the varnish 101 directory onto your desktop. If you don't do that and you try to run off the USB or the DVD, you'll be unhappy person. Make sure that you copy it somewhere onto your hard drive. You will need two gigs of disk space, ultimately four. Once you unzip it, it's not version three, it's just no version three in the end. Unzip that file as we heard before. If you're on Linux, make sure you use the unzip command. Open the sent off 65 vbox file with just double click on if you're on a Mac. I think Windows does the same thing or just right click on it and say open VirtualBox. The box will boot. Should take not very long to boot. Who all is at this point right now? Who has the vbox running? About half of you, okay. The other half of you are you having issues? What's, I'm sorry, what's that arrogant? Yep, yep. Okay, they're actually in rich text format, unfortunately, because I put them on a Mac. That's my fault. So if you have an RTF viewer, I know, damn Mac. You left them on the VM though too, right? I left them on the VM. They're also in the VM itself as well. Whenever we get logged into it, there'll be a directory in there with all that stuff in there as well. Not in rich text. And not in rich text format. So if you're on a Mac, it probably opens up fine, which I apologize for that. Yes.  So reboot if you wish to do this or you can follow on with us. Go into your BIOS and turn on virtualization technology. Any other problems that people are having that don't, they actually wanna get it working. Okay, so try that. If you start virtual box first and then try to double click on the file and then you can import it from there as well. Yep. We'll get to that. We'll get to that. It's on the next slide. Okay, Dan, Dan, where are you at? Can you help her please? Thank you. Is this the CRC or? Don't open the VDI, open the Vbox file. Okay, it's extracted. Oh, you don't wanna extract it. Oh, really? Okay, get a different USB stick and copy off of that. That's probably a bad stick. Okay. Yeah, we hit this, like some uncompression programs didn't like Mac zip for some reason. I don't know why, but any other? It's wild to unzip. Yes, yeah, it's four giga data. It's four giga data, so it'll take a little bit. It'll take probably, it takes seven minutes to copy to that USB because we did it about a hundred times. And that was only half the size. So to unzip it, it'll probably take, you know, five minutes, I'm guessing. All right, cool. So I'm gonna kind of skip over this a little bit. Okay, so if you're on Linux and those text files are in the samples directory, just change the extension on it from text.rtf and that'll fix it. Well, it'll allow you to open it as a different file type. It'll act like the right file handler. My apologies for that, that's my boo-boo. So we kind of already went over this, this speaking HTTP thing, kind of already went to the FastCGI engine next thing. Yeah. Yep, go ahead. So what we found in the past, I mean, so I'm speaking as a black mesh person now. We're doing about 1200 servers, roughly running Apache these days. Different people sites, different scales, different sizes, right, and some of the larger ones, you know, there's like eight or nine web heads using Apache. So we're pushing eight, nine thousand concurrence sometimes on these sites. So those sites, we found that the difference in performance between Nginx and Apache, or I'm sorry, between ModPHP and FPM due to that site, right, it's site dependent because it depends how many modules you have, depends how many PHP features you actually want to include inside of that stuff. All that is dependent upon your stuff, right? So in a heavily, heavily module site, you just have lots of modules, you need a lot of PHP functionality. FPM is probably the right thing. In most cases, most sites don't need that. They don't need a hundred or 200 modules enabled, generally, right? It's whenever you're creating platforms where you're trying to do multi-site for like a hundred sites, and you want to have all those sites, have all these different triple modules, that's whenever FPM can sometimes shine, right? So the answer was the site had a hundred or 25 modules. So anytime you're loading that much code into anything, any site call, you're gonna consume some memory, right? And that's whenever that memory, and it depends what infrastructure you're running on as well. If you're running on digital ocean VMs that only have a gig of memory, then you're gonna, FPM's gonna be the right choice. If you're doing, if you have larger fatter VMs that are eight gig, 10 gig, 12 gig, 16 gigs of memory, then ModPHP typically works, it's within a 5% or 10% range, typically. Yep, next.  The question is, do you have any experience using Enginex Cache over Varnish? You mean as a reverse proxy? So yeah, so I tried it before I got on the Varnish train. Enginex is just not as lightweight as Varnish. It is specifically Varnish is designed to be the fastest reverse proxy, whereas Enginex is designed to be able to plug in and inter-operate nicely with backends like FPM. So there's definitely nothing wrong with using Enginex as a reverse proxy to get a speed increase like that, but the normal configuration that we use in Drupal is always Varnish now at this point. It's been a long time since I've seen anyone do it with Enginex. Yes, you can also catch the FastCGI request. And that comes back to caching and layers, right? So you're caching multiple things at different levels. So you certainly do that though. So kind of to this, exactly that same point, we're talking about Varnish today and Memcache and things of that nature, so just tracking down what Varnish is actually doing. Look at aging headers at this content, find out what the time to live is on it. Our cookie's getting set, and that's what kills Varnish at the end of the day, whether it's dynamic content, things of that nature. And then basically, Vickle, Vickle, Vickle is kind of the thing. So, yeah, it's enough slides. So you guys kind of got to this already. So getting into it, this is the logins. So on your Windows Box or Mac or Linux, open a window that you can have SSH abilities to. SSH to your local host on port 2222. There'll be a NAT role, it'll be set up. It'll be going back to that VM. You can log in with root and it's Varnish 101, and it will be added just to you. So just make sure you can actually get in. Raise your hand if you cannot. That is awesome. Hopefully you're all done typing. Wait, raise your hand if you can. If you can get into it? Awesome.  Half the room, damn it. All right, so we're gonna give you some time to follow along and get into your own machine. Has everybody seen and written down that SSH command that needs to? Because we're gonna take that time to switch up computers here and start presenting the next segment. Yeah, and the other thing, once you get that up, open a web browser and hit those other two URLs as well. Just get those loaded. And that way you have them. So Campbell's gonna have that too. They are not, but they will be. Yeah, they aren't. The slides are not online at the moment, but they will be online after the session. Grumble of discontent. Yeah, so the port, so it's 22 in front of everything. So if you're dealing with Apache, it's 80, right? So 2280 is the non-Varnish version. 2288 is the Varnish version in your web browser. So just localhost colon 2288. And then SSH is 2222. So if you're used to dealing with Amazon or you're used to dealing with off ports anyway, just do dash P and then lowercase P, not dash, cap, P and scp, which is silly. But lowercase P 2222 and then it'll log you in. And if you raise your hand, if you have problems, Dan is here, I think Sean is here as well. Cool, so we'll be, and I'm gonna come up and help you too, so I'll be back and running around as well. Your screen's wet from my stuff up there. I was gonna ask, what is it doing? I can't see. I'm sorry, is it the resolution? Oh, okay, the projector got moved. Oh, it's not me, it's Dan. He ruined Drupalcon. No problem. It just occurs to me. Yeah, I'm just showing you, I'm just picking up probably through, I have to get into a little screen. Oh, you have to switch. It does not display mirroring right now, right? Yeah, it's good. Oh yeah, no. All right, can you raise your hand if you're still having problems and not getting help? Okay, just a couple of people. So yeah, sure, why don't you go have a look and I'm gonna move on with this now. So, what's in the box? So, again, just as Jason was saying, this is sent us six, we try to make it so you don't have to download anything because I don't trust conference Wi-Fi. We have about 16,000 nodes and I forget, 50 users or so, all created with Devel. And the username and password is admin, admin. For the Drupal site that is. Can everybody log in to their Drupal site? On, use 2280, so not varnish. Again, port 2280 is direct to Apache. Port 2288 takes you through varnish. So someone is going to post that URL in the Drupal Con IRC channel. Good idea, right. I didn't hear a yes, can we hear a yes from whoever's pasting that into, done, great. So, I also included in the Drupal install a lot of disabled Drupal modules. Some of them we're going to cover here today. Some of them are in case people get clever and start asking me questions about them so we can turn them on and play. Some of them are just in case you guys are way more brilliant than we give you credit for and we have some really fun advanced stuff that we can do. And some of them are for you to take home and play with. So first of all, when you load port 2280, you get directly to Apache and we see that this is, this is extremely slow. It's a large database. It's a reasonably complicated page that's going through panels. If you want to see a really slow load, go into that primary links menu and hit heavy. So that is a view that I, I want to say it loads 600 nodes at once. Might be 6,000. This is not an unrealistic case. Has anybody here, has anybody else here ever had to deal with a page that had to load 6,000 nodes? Yeah, it does actually happen. Usually not in a river of news format like this unless you really hate your users. But for example, I have one site that is a, that is a, from a budget watchdog group based out of New York and it's not unusual for them to load, for example, a map of all the congressional districts in New York and they're loading three or four map layers or five or six map layers or 10 or 12 and each one has 630 something, 630 something data points on it. Not an unusual situation.  It feels faster, right? So we're gonna do our first very simple denial of service attack. Who here has participated in a denial of service attack against a completely legitimate and not illegal target just for practice purposes? Excellent.   Right. So denial of service attack is a very simple concept. We just flood a site with requests way more than it can handle until it goes down. These requests can be as simple as a ping request. One of the simplest requests we could possibly make. They can be more complicated requests like we're going to do. We're actually just going to reload the front page a ton of time until it goes down. So for this we're gonna be using the Apache Bench. So Apache Bench is a very simple benchmarking tool that comes with Apache. There are more complex and more in-depth tools out there that I encourage you to explore. In this case, as Jason said, what we're really looking for are the big wins. We wanna hang the low, we wanna catch the low hanging fruit, right? We're looking for, I'm not looking for an improvement on the scale of 2%. I'm looking for an improvement on the scale of 200%. So it's all right, a blunt object is perfectly fine. So I'd like you guys to try running this command, A, B minus C, 25 minus N, 100, H, E, B local host. Don't do it against heavy yet, actually. I should change that on the slide. But so this is the way the A, B command works. And you should understand this because we're gonna use it a lot and it's a very good way of telling when your own caching strategies are working or not. So A, B. I'm, yes, actually, so that's a very good point. The question was, do we need to specify the port? So this command, typically you run A, B on the host that is actually running your website. And that's what we're going to do here. You do that because you're not interested in testing things like network latency. You really want to know how much, how much the actual web stack can deliver. So this is a command for you to run from the virtual box that you've got. So once you've SSHed in, and as far as the virtual box is concerned, it thinks it's running on port 80. We use clever virtual box routing so that when you access it from your browser, you have to use a different port. It's a whole other discussion, though. So from that virtual box, we're gonna run A, B minus C is the concurrency. That is how many requests happen at the same time. Minus N is the total number of requests that you're gonna hit. And then the target URL where you're gonna be aiming. Note that you have to have not just the base URL, but you have to have a path. So if you are hitting the front page, you have to have that trailing slash. So has everybody managed to run this with this low concurrency and number? And nobody's computer has crashed yet. Yeah, we're clearly not doing this. Well enough. So now I want everybody to just play around with those numbers. That concurrency number is gonna be a really important one, but definitely the total number as well. And I have a little competition. I wanna know who needs to have, who can get the highest numbers before it actually crashes. Just run against the homepage for now. You can also run against heavy, but you're gonna get a much lower number and you're not gonna win the competition. So I heard somebody say with number 2000, and is that number or concurrency? That was with a concurrency of 500. Sure. As far as command arguments goes, these ones are pretty semantic. Yeah, question? That's fantastic. And you're doing it against, sorry, the comment was that the benchmark fails, run out of open connections before the site fails. And you're doing it to port 80 from inside the virtual box? That is fantastic. Actually, you know what? It might be because we have Drupal Caching turned on, but still, what machine are you running? MacBook Pro. Here is our advertisement for Apple. I have another question? Yeah, I was just wondering if you could explain this. So the number of requests, if you're using one request through Apache Bench, does that simulate a one user if you're gonna try and use this for actual kind of benchmarking? Or is it like maybe 10 requests if your page itself loads a number of assets? That's a very good question. It actually does a full page load. It's just as if one web browser hit your front page. So it grabs all the CSS, all of the image files, whatever you've got on there. Okay, thanks. Yeah, very good question. The forwarding ports for which service? For SSH or? Okay, so the SSH command you want is SSH minus lowercase p space 2222. Shouldn't be any different, but we can have one of these guys come and give you a hand with it.  All right, so we've gotten a sense of what our tools are here. And the takeaway that I really want people to get from this session here is not necessarily about an individual technology. Well, Drupal, all right. But not necessarily about an individual caching technology. As much as it is about having a really good mental model of how Drupal loads data and where you can stick caching systems in order to help with that. So this is a very simplified model of how Drupal loads, how Drupal builds a page. First data is loaded from the database. And then we build objects, components that are going to go on to the page. They're rendered first as PHP arrays and then they're rendered into HTML. And then we assemble the page in HTML. We end up with a full HTML page that we deliver to the client browser. This is the model that I want you to have in your head as we start dropping different caching mechanisms into it. So for example, data is loaded from the database. We can actually put a caching layer in there so that a lot of your database queries come back from cache rather than hitting the relatively heavy MySQL or whatever your backend is. You can cache the objects or the render arrays. Either as render arrays or even as their full HTML. We can cache the components that go to the page assembly. We can cache the HTML after the page is assembled. In this model with the stamps all over it, we've gone from a four step process to a one step process. And the time improves accordingly. So the best practices set up for Drupal, and I use best practices in a loose way because there is a lot of discussion around this, but the most common setup that we have is what we're gonna be working with here. Can I have somebody from the audience read the boss's voice please? Just stand up and take the mic or I'm gonna start assigning it. Who wants to be Dilbert? We have some voice over talent guys. So this is a cute little comic, right? But there is some truth to this. A best practice is what you do in a general case. It doesn't take the specific needs of an individual site into account, but a good best practice is something you can apply in 95% of cases. Part of a good best practices setup is to understand where you're going to be applying your tweaks and how, so that in that last 5% of cases, you still know where to look for your configurations. You know what sort of information you tend to change. You can tweak and improve upon this best practice. There's definitely a lot of room for discussion around it, but the relative improvements tend to be on the scale of you get a few milliseconds out of it. You'll get an extra 5%. Again, not on the scale that we're really looking for here. So the best practice setup that we're gonna work with here is with all of Drupal's regular internal caching enabled, which I believe it is already on the virtual box. We have APC configured with 128 megs of shared memory for those who have never tweaked their APC. Shared memory size, this is a very important one if you like to use APC. This is because APC does not do a great job when it has to clear its cache. It dumps absolutely everything. And if you are trying to put more into APC than it has space to store, it will actually slow down your site with all of the cache clears. It's a pretty fun prank. If you have any sysadmins you don't like. It's not nice. Leave your computer here. I've got physical access to it and all sorts of terrible things. We have Memcache and Redis, as we mentioned before. I think Redis is actually installed that we don't have the Drupal module set up and enabled. There are some complications that can happen there. So we're gonna stick with Memcache for now.  Is that a question in the back? That is an excellent comment. So to repeat that, APC will cache everything that you've got running in PHP. So if you have something like PHP MyAdmin running or any of the other many PHP-based administration tools, those are all gonna be sitting in your APC cache as well. It's a very good comment. So first we're gonna make sure that Drupal's core caching is enabled. This is in, if anybody has never seen this before, then we are in a lot of trouble. Now that I've embarrassed you, has anybody never seen this before? Right, so out of the box, Drupal keeps its caches in the database, which is fine and better than loading and rebuilding everything from scratch. As we heard before, people with even a MacBook Air, that database cache is fast enough that we can't benchmark fast enough to take it down. The important things to note here, since we're gonna be using an external caching system, you really have to make sure that there is an expiration set. So cache pages for anonymous users is obviously a very important checkbox, but you have to set an expiration. The minimum lifetime you don't necessarily need to set.  And it's awesome. Good question. It doesn't matter what you set the expiration of cache pages to, no, not for our purposes here. If you have no expiration set, what happens is that in the HTTP header, Drupal passes a cache control to varnish and says, don't you dare cache this. And that's gonna make the varnish demonstration suck. Since we're going to be doing thousands of concurrent page requests at once, it's all right if your lifetime is one minute. That's totally fine. Normally you'd want this to be a nice long value. Good question. Yep. Let me do that one first and then I'll have you ask the other one. So you guys are my favorite audience. We've done this before so far. I have to say you're asking the right questions. So the question was, is this setup going to be specifically for sites that have a lot of anonymous traffic or sites that have a lot of authenticated user traffic? You're kind of giving away the punchline of my section. What we're doing first is going to be for sites that have a lot of anonymous traffic since that is the most common case for sites that have a lot of authenticated user traffic. I am definitely equipped and really excited to show you guys how to do authenticated user caching as well. We would be using the same toolkit, APC, memcache, varnish. We will have to go back and change these values again, but it's a more complicated question. Yeah, I'll answer that more later. Second question. Okay, so this is another very good question and you're jumping ahead, I think, four slides, but the question is there are certain modules that you can enable that will disable caching for certain pages. And is this going to override that? Is the implied question? And no, this does not override that. And in fact, it's very important that we disable caching for certain pages. There are some things that cannot be served cached to. Click that bit.ly link. It's a gist file. It's kind of like a scratch pad. That way, if you guys can't read any of the functions I'm doing up there, meaning we'll be doing that, watching the varnish log, then you can just copy and paste it from there. I figured that would be easier if I make up a function on the fly. I can just add it there and it'll be easy for anyone to take it from there. And that's it. So I'll leave this up while you guys download that and if you guys can get those, the files on the austintalk.zip onto your VM and then when we come back, we'll go through varnish. All right, so we'll start at 2.30 seconds, about six minutes or so. That should be enough to get up and go if you need to. Pee like a racehorse. Very fast. That's exactly right. Well, it's, yes, that's the idea. So we're going to use cached.zip, right? Yeah. It's going to, it's going to be cached.zip.zip. You don't have to use cached.zip.zip.zip. I can't even remember what we talked about. We want to cache in layers. So for example, varnish might have a relative short TTL or Drupal has a lot of built-in behaviors for when to clear the cached page. And there is the varnish module for Drupal, which means that Drupal will clear the varnish cache for that page. But it's a totally valid configuration to not have the Drupal varnish module have Drupal varnish. Well, Drupal not really know that varnish is there. In which case, you would use cached.zip. Yeah. Clearly, cached.zip.zip.zip.zip.zip.zip.zip.zip.zip.zip.zip. Yes. There's a folder in there called, cached.zip.zip.zip.zip.zip.zip.zip.zip.zip.zip.zip.zip.zip.zip.zip.zip.zip.zip.zip.zip.zip.zip.zip. Map. Yes, exactly. It mostly would only work if you had a short TTL and varnish for really specific pages to cache in. And then we can also do, one example, is I have to say what we actually, we did this for the front page.  She said that we knew where to install it. And we didn't want to be only clearing it every time. We didn't start to use anything. So we can also wrap that up, so maybe we'll put the link up in the comments. Yeah, yeah.  So moving on, when I talked before about knowing your system, caching is more of an art. It's not a science. As Cam mentioned earlier, you know, it's each strategy is kind of going to be specific to your environment. You can use best practices, but obviously, you know, your environment is going to be very specific. And that's what strategies are not transferable means. And then I put a little, I would have used Chuck Norris, but if you're a karate kid would do just as good. So the first thing we're going to go over is hashing. How many people are familiar with the hashing function and varnish? Okay. So the hashing function and varnish basically tells, and I'm going to, I'm trying to summarize this in the name of time, because I think when we get to the examples, it'll kind of make it very concrete. So hashing is basically what it's starting at the end. It's what varnish uses to actually uniquely identify the items in cash. And when we go through the varnish log and we go through the examples, I think this will become very, very apparent. Some people don't really set the hash function. They use a default one. And some people also don't really understand how hashing works. So I have a little kind of example or kind of brain teaser up here. So I have a page and this page has a dropdown of 50 countries. This page also has a dropdown for users to select three different colors. And this is anonymous users. Marketing wants to track an anonymous user selection throughout the site. So we're going to have, so we're going to set a cookie. The site has 10 pages. And the questions, as you can see there, how many different versions of the selection page are there, meaning the page with the form on it. And then how many different pages will be in cash in total? Can anyone answer the first question? Anyone else? And we're hashing on cookies. Can you have a guess? You can select three different colors and you're going to set a different solution. Three. Wait, the site has 10 pages. 150. So you would actually have 150. And then you multiply that times the 10 pages and that's how many pages would be in total. So that's why the hashing function is important. Does everyone understand why it's 150? Okay, so I wish I had a whiteboard. So the reason it's 150 is you have a dropdown that has 50 countries, right? And then you also have a dropdown that has three colors and you're putting cookies. And so since Varnish hashes on cookie, when it sees a first page, if I select France and I select blue, then it's going to say, I have a page and the variables are, let's call the page slash colors. And then the three items it's hashing on are colors. We actually can negate that, but France and then blue. And then I have another one, France and then red, France and then black. And then I'm going to have United States and then red, United States and then blue, United States and then black. Do you guys follow? So it's actually 50 times three. And then if you carry those cookies across each of your page and then you're going to multiply it times and never pages because Varnish is going to see each of those as unique. So that goes back to how hashing is how Varnish uniquely identifies a page to pull out a cache. So if you're hashing function, if you don't understand your hashing function and at the end of the day, how it's actually going to cache that page, then when you get up top, you know, when you start the, if you don't know what's going on at the end and you start at the top, you might think you're caching a page and at the end you're just caching everything.  It's just going to be a very complicated root Goldberg machine that's only not really caching anything. It's not really a caching strategy. It's just saving pages and just basically saving all your pages and then rendering that, rendering them back out to the user. You're not really using Varnish to its full potential. Does everyone understand this bit of the talk? Any questions? Oh, great. All right. So next slide is about cookie control. Cookies are not your friend, as we just mentioned. The best thing that you want to do when you, with Varnish or basically any kind of, I didn't say any caching strategy, is we want to get rid of them because if we have no cookies, we're just serving a basic page with no logic, a basically a static page. So I say, you know, if you're not familiar with this function, this is a great function, meaning like when I see that I'm like, oh, great. There's no logic involved. There's no cookies because most hashing functions usually hash on cookies. So that means it's going to go get the page and then when people come back to that page, it's going to serve the same one.  So we want to get rid of them and we want to use a whitelist. Does everyone, is everyone familiar with a cookie whitelist and cookie blacklist? Okay. So, who has like lighting control? I'm just... Was it her turn to loft before? Yeah. Oh, that works. Yep. Oh, Earthlight Burns by developer skin. So a cookie blacklist basically, it's just a blacklist. You know, you're saying, take these cookies out. So let's say you get a page and you've got 50 cookies and you say, take these five cookies out. Whitelist, like it's just like an IP whitelist or IP blacklist. You know, whitelist just says these are the only cookies that can get through. And that's basically a much more logical and safer method to handle your cookies and varnish. A whitelist also... VCU. Yes, it's on the VCU. Yeah, and we'll be going through it as a live demo in a second. The other thing about a whitelist is if you work for a larger company is that the whitelist forces you, like we mentioned, to drop the noise because you can get a lot of cookies on there. If you've got some type of ad coming in, it might drop a cookie.    And it also forces the business as a whole to work together. If you've got a cookie whitelist and let's say a marketing department wants to drop, you know, a new thing in from some other marketing company, it forces them to kind of say, like, we want it to work this way. And if they know that they can't just drop pixels onto the page without talking to the IT or tech department or developers, you know, then it kind of raises questions of do we need it? You know, what's it supposed to do? And that way, and also for performance, you don't get like a lot of pixels or a lot of added cookies on the page. So it kind of forces everyone to kind of say, like, okay, you know, I'm going to, I want to put this on the page and I want it to redirect on users who have X, Y and Z. And so, okay, we have to allow that in and then we'll make it efficient instead of waking up one day. It's like, oh, there's a new cookie on the page. And then you have to kind of do a blacklist to pick that one out. And there might be a new cookie, you know, every week. I mean, it's different if you're working for a larger company, you probably experienced that maybe for small, even for small shops, if you're doing something for a client, you know, they might drop a new something in, like, oh, we want this added, then you'll have more cookies on the page. So a whitelist is a very good idea. So we're going to go through the first example, which is a voting with a whitelist and a hashing example. So, I'm going to switch over to, and I'm going to, and I'm running this on my local because it's, I think it's going to be easier for me to kind of zoom in so you guys can kind of see the code. And I'm, so I'm not running on my box, but you guys should have the same files. So does everyone see that file in there called AustinVote.php? Yes, no, maybe so. And also you guys should have open that link with the GIST file that has some helpful little snippets we're going to be using. I'm sorry? I do. Are they not showing? It must be mirroring. Okay. Where's that mirror? Some preferences. Display. Show all. All right. Can you guys see now? Is that too small, too big? Okay. It's very, yeah, it's wrapping around. All right. Okay, so we're there. Okay. So if you guys want to put that, Austin, that's vote.php and your your dub, dub, dub, dub folder so you can get to it and then bring that up in a browser. Yes. A varnish 101. So I have an anonymous window open here. And is anyone having trouble getting to working with the page now? Okay, so you can see I have no cookies right now, and then it's just a simple form. And the other thing to note is that right now, actually let me back up. I know I saw a lot of hands about the Vickle file. Do you guys have the Vickle file open right now? Okay, so I'm just going to go through the example on the assumption that everyone kind of knows the Vickle file, and I won't go through how the varnish cache miss goes in there, but we'll be going into it. Anyone who hasn't been into a Vickle file or done much with it hopefully will kind of pick it up. So I'm going to refresh it again, and then you will see that it is a now it's a hit. So when you see this varnish cache hit, that means it's being served from varnish. And we know that, and due to these lines right here, this VCL deliver, if you're not familiar with it, it just means what do I do when I'm delivering the page? And we just say if you have a hit, meaning you found it in cache, then set hit. If you didn't find it in cache, then you set miss. So now that I'm in the Vickle file, I also kind of, like I talked about earlier, I like to start at the end, meaning the hashing function. I don't know if you guys want to open your Vickle file, if you have the hashing function in there. Do you guys have the hashing function in there? Sorry, if you go to var in your virtual box and etc. varnish, there's a default VCL in there. And then at the end of that, if you guys want to add from the gist file this hash function right here. And so let's go through the hash function. As I said, a lot of people like to cache on a cookie. So we say if the request has a cookie, then add that to the hash. And then we also say this is for later if it has an X device header. And this is for a later example. What we're going to do is we're going to make varnish do the work of detecting if this is a mobile device or not, and set that as a header instead of having Drupal do that for us. So that's kind of for the later example. It's going to cache it, but it's not going to hash it. So does that make sense? Okay, so it will cache the page, but it will not add that to the variables of how to uniquely identify it. So our buckets right now are cookie and device. So if you think about it, it's going to say this page right here. I have no cookies.  And then if I have a cookie that says blue, then it's going to say, okay, the variables are, you know, it's like a select from a database. Give me the page Austin vote where the cookie is blue. And then it's going to pull that one. Yes. Yes. Yes. Yes. All right. And then does everyone have that added? The hash function? All right. So and if you have trouble with it, I'm just going to continue on. Well, well, meaning, meaning I'm, yeah, if you, if you have a question, like raise your hand and then we'll try and help you. But just with for, for a time, I just kind of want to make sure everyone sees the concepts and I can get through the examples. Yeah, that came out wrong. So. Don't worry. It was recorded. Yeah. Okay. So in the guest file, there is at the bottom this varnish log. And if you're not familiar with varnish log, it's basically varnish log. It tells you what is going on in varnish. And there's varnish. There's a comp, not really complicated, but it basically uses a shared memory file and it reads from that. That's why you have to use varnish log to read the log file. So if you want to use this function and then open up a terminal. Okay. So what I'm going to do now is I'm going to show what's going on in the log file. Are you using port 2288? Yeah. All right. So I just, I just hit the page in my browser and then this is what comes out from the varnish log. I'm not going to go over everything that's happening right now. But what I do want to go over is the hashing function. So you can see right here in this hole, we're going to look at this as we go through. So like we were saying, the URL is in the hash. So here's the two URLs. And then it just kind of goes and it's telling you this is, you know, this is what I'm using the hash. And you can see, I restarted my varnish so it's a miss. So what I'm going to do now is I'm going to, blue, blue is my favorite color. I'm going to submit that one. So now my favorite color is blue. And you can see it's a miss. And you can see the hash has changed. The color is blue. And so this is the criteria that it's going to be using to cache this page. So the color is blue and here's the URL. So that's, that's the, when you're talking about, is it going to hash and not cache? The page, but it might not always hash depending on the criteria that we're using to, to cache the page. And if I use this URL on another browser, you can see that my net response, no, that's a cache hit because it's just pulling the page that is in the cache already. And we can also do it without even selecting. And as we said, it's using certain criteria to cache the page. I'm going to go ahead and create a cookie. The, the name is going to be color. And the value is going to be blue. And I'm going to refresh the page. And you'll see it's a hit. So because it's pulling from this page, since they're anonymous users, it knows that's the same page. So it's not going to do any PHP processing. It's just going to pull the page. So that's kind of the basics of the hashing function. Any questions about that? Yes. I'll add extra headers. No, this is a, this would be a basic page. So there's in the download zip, there's a page called Austin dash vote dot PHP because I just want to go through the basics without doing the complications that Drupal will add to, to the caching layers. So for people who are still getting misses from varnish, make sure that you restarted varnish since we updated the protocol. Number two, make sure that you are logged out of the Drupal instance. That's on this, on this virtual box. Otherwise your browser is going to send Drupal's cookies as well. And there is no number three. Yes. Service varnish restart. Well, you don't need to pseudo. You already root. Yeah. Service varnish restart. Okay. All right. So that's kind of the first example I wanted to get is basically the hash, the kind of general strategy. And we can talk more about that kind of running short on time and how the hashing function works. So I'm going to switch back. Actually, I kind of want to go to the next example. So I'm just going to talk through it. I don't need my slides for it. So the next slide just kind of says, you know, and these slides will be up on the, on the talk page. Bless you. So, you know, now the next question is, you know, that's it. You know, is that all I can do? And it can do a lot more. How many people have to deal with detecting mobile browsers? Okay. And what do you guys generally use for that? CSS? JavaScript? We actually do it in varnish. You do do it in varnish? Okay. Yeah. Okay. Yeah. So with varnish, one thing, there's a lot you can do, but ways to move things into varnish will help you on the back end or even you don't have to do that kind of detection, whether it's we're going to do an example for mobile detection, but you can do a country location, you know, figuring out where in the country they are and address and what not all in varnish before you even hit the back end. So that way you're dealing with a page or you can cache that page without having to process it on your back end and varnish is going to be much faster at it because it's written in C and it's just made to be very lightweight and very quick. So with the mobile, and this is with the mobile example, what we're going to do is we use a library called mobile detect. I'm not sure if you guys are familiar with it, but mobile detect is maintained by browser stack. And within the zip file, you'll see this mobile detect.php. And as we mentioned, yeah, it's a big file.  And regexes are something that varnish loves to do. It's basically when you're manipulating cookies and what not, you're always doing regexes. So to get clever with it, there is a module in there called austintalk.trust.inc. And basically what it does, and we're running short on time, so if I'm going too fast, I can talk about this offline, but just the strategy of it is that instead of having to go to the back end and or having JavaScript do it, but going to the back end and doing a bunch of database lookups, or if you're using browser cap, it also, browser cap does database and mobile detect does a regex. We can have varnish do it. And what we do is this function basically just builds a regex and then it builds a vicle include file. And we can see it's a submodule. And what it does is it basically takes the user agent that varnish provides us and it basically does a regex based upon the mobile devices that mobile detect would already use. And then it sets this device header called mobile phone. So, to see that action, once you run the Drush command, you'll get this file. And then if you want to use the file, then you would add it inside of your vicle, or sorry, you would add it to the same folder as your vicle, and then you would do an include. And on the gist file, you'll see this line right here. So, if you open your, your vicle right here, and at the top, your pass will be different, but you'll see this include. And you want to include wherever you put this mobile detect.vcl. And then if you scroll down, or you know, page down in your vicle file, somewhere above, I like to do mine around the cookies, you'll want to call the function, which is mobile detect. And this is going to do the regex for our mobile detection. So, so what we've done is we've created a file that will do our mobile detection for us and varnish. So, I'm going to open Safari, and I've already got, and I use the developer tools to set my user agent to iPhone. I'm already on iPhone. And if you notice inside of AustinVote.php, we look for that header and we say, if there is an X device header, which would come from varnish, then say this is mobile, that way we know this is a mobile device. So, a few interesting things are going to happen here. So, you want to add that file, and then we need to restart varnish. So, I'm going to go ahead and restart mine. All right, so my varnish has restarted. So, I included, let me call, it's not on iPhone. So, now I'm on iPhone and you'll see it says mobile. And then further, if we look at our varnish log, actually, I want to restart it so we can see that from the beginning. So, it's a miss, which is fine because we restarted, but we talked about that hash function and knowing what your hash function is doing. You'll see we added this device header that I said would be used later, and it's also, you can see it being used here in the hash function. It's using the mobile phone header that we, device header that we set, the URL, obviously, and then there's no cookies yet. And so, this kind of goes back to that conversation about, you know, we have a drop down to 50 countries and we have three options and how many different pages there will be. So, if I select blue, I like blue on mobile phone, but more importantly, in my hash function. I'm now the color blue, mobile phone, you know, and the URLs. And if I select red, same thing, so you can see the combination that's happening as we grow. Excuse me. Oh, yes. And we're just, actually, out of time. I probably won't have time to get to the other things, but do we have any questions so far? The dress command? The dress command is going to be AT-talk, I believe. AT-mobile-vcl. And it's in that downloaded zip file, this, all the code here. Yeah, so if you open up that, it's all there. And it should be said before we do questions, we are all around the conference and really happy to sit down with you in the sprint room or at the black mesh booth or at the forum one booth or wherever to go through your own individual issues. And one more thing is I looked on DrupalCon's website. They actually have a Drupal Association YouTube channel. This session with these slides and everything that went through these laptops will be on a YouTube video. It says it basically puts it up a few hours after this, so it should be available at the end of today. So if you just find the Drupal Association's YouTube channel, you'll get all these slides as well as having us talking to them. We're trying to upload the PowerPoints as well. It's just very slow on conference Internet. Yeah. Exactly. That was the other part, talking about offloading it, is that I was going to talk about as devices change, they're always changing that you can just run this Drush command and then just do a varnish load by recompiling while running without having to shut down your servers and restart. When you're getting a million pages out of it, it's important that you don't want to have any downtime. In the far corner over there? Yes. So the question is, can you hash just on certain cookies? And the follow-up question of that one is, can you hash in different things? Maybe you want to hash in a different URL. The answer to both of those is yes. In the Vicle, you'll kind of see in the white list the cookie headers and then I wanted to get through the white list, but basically this is what it does. I could send 50 cookies at it and it would filter them all out except for these two that I've allowed through, the color one and the Drupal visitor color. And as far as the URLs, yes, you can also manipulate the URL and that's good for things like if you want all pages to be saved as www.example.com and someone comes from www.example.com, you can manipulate it and say, add www if it's not there so you can kind of normalize that. So yes, on both. We've got a question about a website that has maybe a feed of some sort on it that is somewhat more dynamic but it's still anonymous. Are there solutions for still using varnish, not using cookies and stuff like that and not using like JavaScript to reload that little version of the DOM. Was that clear enough of a question? It seems very clear to me. So there are a few options. If it is a static file, the normal behavior that you write into your vehicle file is for varnish to pass through which means to just directly pipe from the back end which is as direct as you're going to get coming out of the file system but a generated feed like we tend to use in Drupal you can set the cacheable lifetime based on really whatever you want out of the headers including things like the file extension or the specific URL. So you could say this has a lifetime of 5 minutes. A nice short lifetime which will save your server a ton of load if it's actually being hit. It sounds like you also want to use an ESI. Are you familiar with ESIs? So I didn't get to those but if I understand your question correctly you have a page and you have a little widget that needs to be updated then probably if I'm understanding correctly you could use an ESI and have it such that when that ESI is served it has its own cache headers of when it should time out and what not. Alright guys we really are out of time. We have to let the next session come in here. Please do come and approach us in the hall at the booths at the sprint room. Thank you very much for your time.


Hey everybody it's Hari Swaminathan from optiontiger.com, it's Tuesday August 6th and we are closing another good trade, you can see the gold trade is up about 900 and we've booked already 500, so this becomes a $1400 trade and in terms of ROI this is like 100% because as you can see we bought it for 1.33 and we've already booked 500, that's what makes it a nice trade. We're going to hold Netflix, it's a good profit but we'll hold it, we'll keep it as a hedge and I'm going to close the Bailu bear call as well, this bear call is up for 70 but important we'll close the gold trade as there's only 10 days left and some time decay will start to kick in at this point so there's no point in holding it any further. So this is about 900 plus 500, 1400, thank you. So this is about 500 plus 500 and we're going to close the Bailu bear call as well and we're going to close the gold trade as well so there's no point in holding it any further. So this is about 500 plus 500 and we're going to close the gold trade as well so there's no point in holding it any further. So sign up on a monthly plan for 25% off or an annual plan for 50% off the list price, thank you.


Here's a Hubble image of Able 2744. It's 4.2 billion light-years away. It's named Pandora's Galaxy Cluster. It acts as a gravitational lens into even more distant galaxies, seen as bluish distorted lines across the cluster. Here's the view from Webb. You'll note that the distorted images of the more distant galaxies are now reddish. Just because this is seen through Webb's near-infrared camera. Zooming out, we see areas that have never been imaged by Hubble. Astronomers estimate that there are around 50,000 sources of near-infrared light in this image. Bright white sources surrounded by a hazy glow are the galaxies of Pandora's cluster, a conglomeration of massive galaxy clusters, coming together to form a mega-cluster. The concentration of mass is so great that it produces one of the strongest gravitational lenses known. It's the lensed galaxies themselves that are the object of this study. Astronomers used a process called photometry to estimate the distances to the many warped background galaxies. The technique measures light intensity through various filters and compares the results to a database of model galaxies. Notes showed that six of these seven galaxies that are close together on the sky are also at the same distance behind Pandora. Later, spectroscopic analysis, which takes a good deal longer to collect, determined conclusively that all seven were at the same distance with a redshift of 7.9. This would make them all members of an early galaxy protocluster that formed just 650 million years after the Big Bang.