 Yes, let's just get started. So, thank you for showing up. I hope you know this presentation is about Drupal performance from a beginner level. Unfortunately, the word performance got dropped from the program, so if you're thinking this is about anything else, notice the time to leave. So, my name is Paul Krischer. I'm Dutch. I live in Harlem together with Denzie, my second-based fan right here. My job title is that I'm a customer success engineer at Acquia. Hardly anybody knows what that means. I'm still finding out myself, but I describe it as such that I help all new enterprise sites land around the Acquia Cloud Platform as smoothly as possible. So, from the time people signed the contract with Acquia, till they launch a little bit after that, I take care of them on a technical level. I help them with some best practices on performance or security or all kinds of other things, technical, and make sure they're successful in Acquia Cloud. They, they kindly provide me the time and money to be here today and they're sponsoring this event. So, I hope you'll visit us at our booth. We have so much to say. On Drupal.org, I go by this name, S-Q-Y-N-D. I pronounce it a skit. Feel free to butcher that in any way you feel fit. I also go by the same name in Twitter. That's about all social media. I don't do Facebook and many other things. But Google me and you'll probably find me. My claim to fame is that I'm the original owner of the Poets module for Drupal. So, if you were using Varnish, there was a Varnish module and an interactive Drupal with Varnish directly over the Varnish administration socket. If your security guy or a guy couldn't make that work, this was the alternative module. I've done the Drupal 6 and Drupal 7 versions of that. I'm actually not a really good programmer. So, the Drupal 8 version, I've left to a colleague of mine called Niels. He's going to be taking it over to the next level for Drupal 8. I'll tell a little bit more about that. So, I wrote this presentation for beginners. That's how it was announced in the program as well. I still think that, at least in my experience, at least some of these topics are missed by some of the more experienced Drupalists as well, performance is usually not the first focus what people think about when they're building Drupal. They want to build functionality. So, performance is probably not in front of your mind when you're building your Drupal site. That's why I hope to educate a few things here today on Drupal performance on a basic level. I'm not going to give you the nitty-gritty on how to do exactly this module configuration on how to do Varnish VCL for Drupal 5.1, whatever. That's not the focus of it. If you have any questions about it, feel free to come approach me anytime during this conference. So, why performance matters? The most prominent aspect is the human behavior aspect, right? People are impatient. So, if your site takes too long to load, at least in the perception of the visitor of that site, people go elsewhere, people lose interest, people find that there are 22 tabs on their browser that they find more interesting and you've lost it. If your site depends on visitors who are being successful, your business depends on it. That's what you like. Some investing already in performance for that reason, a lot of that can help you. Then again, Google likes fast websites, too. They will rank your site higher in Google Index if it performs faster. So, search engine optimization is another reason why performance really matters. Then also, if the application you build in Google performs really bad, and it's going to cost you a lot of server capacity to make it work at all, you're going to spend considerable amount of money sizing those servers and spending money on infrastructure that you could have spent elsewhere. So, one another more. And since, you know, if you're saving infrastructure, if you're saving your bandwidth bill, if you're saving your electricity bill, you help the environment insert your favorite cute animal here, they'll be happy as well. So, when to start thinking about performance? Start now. Start even before you start developing things. I see too many cases where performance is an afterthought. Oh, yeah, yeah. We built this awesome website. It looks great. Client is happy because we demo it locally and it works great. The first 10 visitors hit it and performance dropped to a standstill. And just after lunch, it's not really a good time to start caring about performance because then, you know, Google is already looking at your website. Your most interested clients and visitors are scanning the website and making up an opinion. That's not when you want to give them that impression that you're slow, you're slow as hell and, you know, keep them waiting for those next pages and the next interactions. So, I would recommend start measuring right away even when you just hit the last submit on your Drupal installation script installed PHP. See how long it takes to log in and load that first website and see that as a benchmark. You're only going to make things worse after that. So, let's at least see how on your infrastructure, how your code base performs on every stage and keep measuring that. So, at least you know when that's degrading and it's probably related to one of your last few changes. So, if you just measure something really, well, hey, what did we do yesterday? Oh, we did this enormous form that we're already testing now as well. Maybe there's something to be cashed in that form or some optimization you can do there. Or at least if it's something that you accept and at least you know when, what happened you may even want to talk to your client and say, yeah, we probably want you to lose this feature because it's really taking the side performance down. Early in the process, that's hard to do when you're done, all right? So, let's start doing it. So, what is fast? How do you measure that? Just click around on your site. You as a human already have some experience with the web, I hope, by the time you go to Drupal site. So, you will already know when something is slow, right? Use your own instinct and your own gut feeling if you think something is slow or not. Because you're probably really right, right? And we as web developers we have amazingly fast laptops at least mine is pretty old, but it's still fast. Moore's Law is dead anyway. So, use that as at least your gut feeling. Then, use your client. Demo him an early version of the site and see and ask him straightforward what do you think about this site performance? Because you can measure all the milliseconds and all the stopwatch software that's out there. But if you as a human or your client is going to pay you to build this or if things are slow you can measure all you want but at least something that you need to fix there. So, start with that. And trust that. This still helps if you can have some more scientific approach to your measurement. I'm mentioning a couple of tools that you can use to do that. There's literally hundreds of them out there. I'm quite old fashioned. I still use Firebug which is a kind of anti-created browser built extension. But it has everything that I need and I've been using it for over a decade. So, use that. But at least that will show you a timeline of okay, this is when we requested the first page and this is how long it took to render that get all the assets in and this is when the site is done. It will tell you up to the middle of the second how long that takes for that request. Why slow is a nice plugin for Firebug that also will give you more explanation and recommendation on how to fix some of your basic performance and use when it comes to website performance. It's not Drupal specific but most of the things that I mentioned apply to Drupal just as well as on any other site. Have a look at your server log. How many sites did you process in one hour or in one? And how much performance do those data do those logs have in them? I'm a big fan of New Relic. It's a cloud based performance tool and it really integrates nicely with Drupal. So they have a Drupal module out there and you can install little engines on your server and it will literally provide you with loads and loads of really significant performance related data. They have free start-up lines and demos that you can try for a few weeks and then still basic monitoring is still for free with these guys. So I highly recommend you check them out. It's really pretty as well so it's something that you can even have your client have a guest log in so they can have something to click around with and be proud of all the color graphs that are out there client-like color graphs. Use that as well. If you want to do it yourself want to go more deeper, XDBurg is one that we use a lot of Dacquia as well. It's similarly detailed, not really Drupal specific, but if you want to drill down in which PHP function or database query or whatever got you in trouble, you can find that in XDBurg as well. And like I said, there's others out there take whatever tool you like or your colleague recommends or a blog post you read somewhere I recommend you. Then how much performance do you really need assuming that there are going to be more than one person visiting your website. So even if you measure something in your local browser that's just one visitor on a really powerful machine that's probably faster than the server you're running or at least the shared server that gets sold to you as a VPS. So how many visitors will hit your website? Try to have a reasonable estimate on what is your peak traffic. If we ask about peak traffic to clients many times we hear, yeah every month we have about this many thousands of visitors. That's really not the metric you're looking for if you're looking for peak performance. We don't want to know the average we want to know what is the peak how many visitors are on the site at the same time at which minute, minute at that very minute. Because that is the peak capacity that your server will have to have be able to take on the load that you're sending to it. So for a client to come up with better metrics or monitor it you know usually sometimes even the client itself or the development team that is working with the client doesn't know but I'm sure that if they have that advertisement on it they know exactly when they sell most apps. That's what you're looking for. We'll tell you something. When it comes to server performance and resources memory is usually the most limiting factor. So at least in my experience unless your site is doing really heavy computation so if you're resizing videos on the fly and encoding them in three different formats yeah CPU is your concern but in my experience at least most Drupal sites that I see memory is the limiting factor. So the more memory you can have available the more concurrent PHP process you can handle the more visitors you can at least have bootstrapped Drupal fully, have a bird shape a page shape and then have that be delivered to the visitor. So at least you can help an expert as soon as possible. So calculate the limits of how much memory do you have. Most PHP instances servers if you install a PHP engine on your local environment on your web server it will probably reserve 128 megabytes for each session sometimes lower, sometimes more depends on where you go. We had actually had 128. So if you then at least protect your server by limiting the amount of PHP processes you can handle by calculating how much of that memory you need you can at least make sure that your server is not demanded too much of and make sure that you have memory to serve each of those users and then the next person ends up asking something that is no longer available which is the next PHP process and at least they can just say sorry we're too busy but at least your server will stay up and running. So restrict that memory to what you can. Sometimes I literally get request please increase the memory limit in 2GB because I get these nasty errors. If you do that you will literally limit the amount of PHP processes from the default of 128 by 16 fold and really bad at calculus you can probably check that but that means the number of users that you can help is really reduced. So see what kind of server you have see how much processes you can fit in that memory and limit it to what you have there. Right? Then if you're testing things if you overload the system that server will end up running some system will have something like a swap file so if you ask more memory than there's physical memory available it starts to replace really fast RAM memory with really slow disk memory that mechanism is called swap open windows and in Linux don't try to avoid that whatever you can it's sort of a safeguard so in the way it's better than just bringing down the server or getting an out of memory issue you're in trouble anyway so we are not going to even disable swap and if you over book we limit what we can to make sure you don't end up in an out of memory issue but if you're running out of memory your server stops if you need to restart it that's the way out of that so whatever you do don't kill servers or at least the pull bastard has to help you restart it so planning just like this there's no use if you can break a server or if you can throw as much traffic to a server that it will collapse on the roll out there's no use for that I sometimes see people that say low tests and they just send 2,000 requests to a server that only has capacity for maybe a hundred yeah you broke the server well what else did you learn not too much so try to see you just did some copies you know what the capacity do you need try to make your test at least a representation of that and learn from that can I handle that scenario how much capacity do I have oh I know that I've made some calculus and I said well I should be able to have 150% of my peak that I know which is a nice margin to have just for that go a little bit over see if the server can handle a little more than it's supposed to do sure that can be really educational but either doing way too much or too slow you know you can still test your application on your local server and with one request it doesn't really learn you you really learn a lot by sending at least a few parallel requests and see how your application handles that if there's any bottleneck you probably will find it with about 25 users it's my opinion some people think otherwise what's really important to distinguish is how many people log into your site as I will talk about later there's a big difference between people who are authenticated against Drupal and pages that we can cache and then we use for any other anonymous user requesting the exact same information so make sure that at least if you have a login feature for your site where visitors can login or at least interact with a way you know maybe have a form there that's unquestionable as well so how many of your visitors will actually hit Drupal on each and every request make sure you have the percentage and commit to that because that will really depend on how much server capacity you need and again be in time don't do this two days before launch sometimes we see clients finding critical performance issues before launch we just tested the site for the first time after a half a year of development and now we need to postpone our launch and it really happens a lot to you start early do a little test now and then make sure you don't end any surprises so there's a zillion tools to load test the easiest one is your F5 button on your keyboard which is reload on browsers but still you know what happens if I hit F5 it's really fast then you're probably getting something served from cash it's really good right if it's really slow something is wrong already you're gonna find that same if you send 100 user or 2000 user to that same site so better fix it early some people are really nice with scripts and know all the command line options of that tool called Curl if you can do that if you know a little best way to do it try to find your own I still find that's usually more educational more useful than hitting all of the ready-made tools I'm gonna mention a few anyway Apache benchmark it's quite primitive but what it can do is it ramp up really nice and slow so at least know when something breaks and have it react to that or log that really nicely AB should be on most Linux distributions Jmeter is really advanced it's a Java application it's open source if you have a workflow that really depends on a login and then a complex commerce form or anything that it depends on cookies or state you can probably program that in a really advanced Jmeter script so if you're doing something that is really not so easy to build in a simple script or by just hitting the top five URLs that your marketer says are your top five URLs Jmeter is only where you want to look it's quite complicated you can make things really easy but you can make things insanely advanced as well if you don't want to run it yourself Blazemeter is a tool we recommend a lot of Acquia it's a hosted version of Jmeter so you don't worry about all the Java crap and just have it hosted in the cloud they even have a free offering so register and point it to your website see what happens it's quite educational and you're still going to upload your advanced Jmeter scripts to this cloud and say ok and now one of them if you pay them you can submit a few thousand people or at least virtual people to your site and see what happens now so after you've done that you probably have an idea where your bottom neck is is it authenticated users, is it network capacity is it so what can we do to fix things this is a quote that I remember a Dutch Drupal is telling me back in 2008 he showed me a really early version of views for Drupal 1 and he roughly translated like anything in Drupal it's painfully slow until you turn on caching and that applies for views in Drupal 5, 6 and even in 8 anything in IT basically so if you look at your machine even in your phone there's like at least 3 or 4 layers of caching everywhere every component in every IT solution up there realize that if we didn't have the concept of caching we all would be out of a job really or at least paying a lot more money to the server infrastructure providers that we all rely on so there's CPU caches, disk caches all these kinds of caches one of them is not a cache find it it's the most fun one so in Drupal we have a lot of layers of caching as well we have block caches menu caches, page caches we have really advanced cache solutions which are still experimental but if you have a mix of content that is served to anonymous users and authenticated users you really want to check it out because that really efficiently combines those two in a cacheable, at least as much cache as much as we can and sort of last minute deliver anything that's personalized on the website it's really nice my colleague Ren Leus built it together with Fabian one of those other TechOne consultancy firms really great guys and there is Drupal called in Barcelona and they presented all this so if you're interested in doing advanced things on mixing those variations of caching check that presentation out many people still should be realizing views and panels and many other more advanced module solutions out in Drupal have their own caching layer so even though your site may be personalized because of a few blocks here and there that have a shopping cart or a hello user with their name on it or whatever if the view that you're presenting in that page can be cached turn on caching it's a little hidden in the corner under advanced but every view should be able to at least have a cacheable solution to use whatever it has you can even separately set parameters on how long to cache the complete rendered view or even do just the query so if you want to change some rendering later on or there changes you can have separate parameters for that highly recommend you check it out later on a little it can really save a lot of performance on your site just one thing to mention in Drupal 6 and 7 set form use the term form cache the form cache table on the form cache machine is not a cache it's a state engine it happens to use the same mechanism as the cache system that we have which was a bad choice so it's different in Drupal 8 take care of that so where to store caches in Drupal you can by default put it in the database because that's the storage engine that we have available anyway if we use Drupal sometimes it really can help you if your performance sees a bottleneck in the database or you see a lot of more activities in those cache tables in the database using a separate store for your caches can be really useful at Acre we use Memcache I'm sure you heard of it there's technology coming from Facebook it's not really secure by itself so you need to take care and secure that ask your host provider if you can help you with that of course we have it at Acre some of our competitors prefer Redis it's a different solution out there I'm honestly not so familiar with it but I see it's being used quite widely as well MongoDB is another of the usual suspects and it's sort of died down but like every two months somebody new wrote a new NoSQL back end so there are probably going to be quite a few more and still a field that is in motion quite a lot so if you see this presentation in three years from now there's probably other ones that you want to check out the good thing about Drupal is there's a module for that so by the time that an emerging technology comes out somebody already wrote a module for you and you can just build on that so keep an eye on those so what happens outside of Drupal the cache that everybody gets for free is your browser cache many people still frown upon it I hate browser caches and they have some extension that turns it off because developing where the cache is irritating like because you almost always need to invalidate or clear it over there where it's called I encourage you to at least learn how your browser cache works and I'm going to explain that here so all kinds of articles out there Google for it I recommend you to at least understand what happens if a browser thinks it has something in cache that it can reuse, how it verifies this and how it can make best use of those mechanisms already in place for free, you don't need to do nothing about it and Drupal plays really nice with those maybe for so if you go to the performance setting in Drupal you can set at the time that something will remain in cache it's off by default I always recommend that we put at least 5 minutes in there then again we sometimes are now able to convince clients to extend that to a week or a month I'll go into that a little later but the better you do it, the least chance a browser or those proxies needs to come back and re-fetch and regenerate the same response the better it is for your own performance reverse proxy caches are literally systems that stand between the visitor and the web server the most popular one is varnish cache there's quite a few others out there but I'm a big varnish fan as some people may know so check that out, it should be quite straightforward, most of these engines really try to follow all the rules in the HTTP server protocol and make sure that we bother Drupal as least as possible by asking them the same for the same response every time so if an anonymous visitor hits any URL your own page or any other URL and it sees it has a valid response to that already generated for another one it will just serve it right from the varnish cache memory and make sure that you don't even hit Drupal avoiding all kinds of relatively slow Drupal bootstraps who then need to hit database caches who then need to a memory cache sorry, a cache memory storage or anything like that so again it's least something that you should if you care about performance and you have something that you massively scale learn a little about them you have to I still see clients who are really great at PHP and web development who don't care too much about servers you don't need to run your own varnish instance you're asking them to provide or should probably take care of that for you but at least familiarize yourself with the mechanisms I still sometimes see people who literally have a little trick that adds some random noise to each URL I'm asking why are you doing that you're killing your cache threads that you use why are you doing that yeah, we don't like varnish, it's always in our way we are a real time company and if we change something to see it outside so varnish is more in our way okay trying not to do that it's really try to spend a little time educating yourself on what that varnish cache or that reverse proxy cache or what any other kind is doing for you because it should be helping you in a way that you can use you know, optimize that and make sure you don't get hit by that problem that you perceive to be having right a CDM content delivery network is literally that same reverse proxy cache that's signed between the visitor and your Drupal instance but then on global level you just go to a company that has a whole bunch of these systems all over the world and they're literally trying to be close to your visit as well in the US and maybe even inside of this firewall in China which gets complicated and I'm going to that but there's people who do that and make sure that if you're a global brand you don't have to go all the way around the world to get that response now it's already coming from a cache in your neighborhood probably in your ISP network so I'm a big fan of Fossily they use varnish cache as a CDM I know a few people work there I mentioned them first Akamai was earlier to the market they are the biggest ones they literally have points of presence in nearly all ISP networks all over the world so I used to work at KPM at KPM and Dutch ISP and they literally had an Akamai island in their hosting environment and so if you hit anything that's coming from their content delivery network you don't even need the ISP network so it's really efficient you're ready for that another nice option is Cloudflare they're quite cheap they even have free options so I recommend you just play around go to Cloudflare, register and see what happens to your personal life if you feel it's improved just point DNS to it you should be able to have some nice performance for free and there are hundreds out there so these are the ones I know and there are more like I said cash is the longest possible I already mentioned that there is something really advanced it's called ESI Edside Include where you can either tell a varnish instance or your CDN it's actually technology first implemented by Yahoo but Akamai was the first CDN to implement it as well where you actually assemble components of your website on the CDN level so not in Drupal but say ok let's send out a response to a cache, make sure it gets stored and all those caches all over the world and then for a little block that's personalized or maybe regionally independent let's inject that on the cache level be careful because I've seen people who think they understand I always think this is one of those mechanisms but the harder you think about it the greater it sounds so I've seen an implementation of a newspaper that actually managed to have 5 components being injected in this method that I'll just explain so for each page view they bootstrap Drupal 5 times and that's slow maybe probably better off just assembling your side of Drupal so there's a module for ESI for Drupal 7 and 8 be careful what you're doing there make sure you have some good measurements if you followed all the other things that I recommended to you you're probably ok but still so how do we manage to get clients to extend their exploration time for their caches to up to a month by making sure that if something changes we eliminate that from their caches so the term you see used for that is purge that's the little module that I wrote that interacts between Drupal and a varnish instance or CDN that supports Drupal as well there are quite a few options for Drupal 7 so there's a varnish module that only talks to varnish over the varnish protocol you have purge that does things over HTTP it can do engine x varnish and quite a few others there's quite a few platforms specific so for most of those CDNs that I just mentioned there is a purge module so if you have Akamai purge, Cloudflare purge Pothly purge, whatever purge for Drupal 8 we have now sort of a trend that we really try to have one generic purge module that has plugins really quite advanced Drupal 8 stuff but hey if you just install that module and click enable it you can really easily make sure that you take the best advantage of this really advanced Drupal 8 mechanism that we have is called tag-based purging so what happens I'm going to point you to Wim Leers again who implemented this for Drupal but it's already in Drupal Core the purge module uses for this is used for this each response that Drupal gives out it adds a header that contains the unique identifiers for all of the components that are used on that site so it's this block, it's that few it's this header it's this image, it's this node it's this list of nodes and it will squeeze all of those identifiers in a tag header then if one of those things changes we can find hey this is the tag that we use for this component and we can tell Varnish VN or combination of those drop everything that you have that contains this so we really if something changes and Drupal knows what changes we can have instant invalidation of everything that just changed by forcing then a refetch of all that content that just changed and for all the rest we literally keep everything in cache for maybe a month we've literally had one external client that implemented this before we can do it on our own hosting platform and they literally retired 80% of their service that's a big saving consider using that for your next Drupal 8 site you save some some cute animals there so that's all delivery and cache it on the front then what is left then usually something in the database right the query of death by a module just you wrote yourself and really you're not the SQL expert, I'm not a SQL expert maybe a colleague here so we can help you with some performance then again there's also some functionality in Drupal that can really bite you the most easy way to win some database performance turning off your Drupal database a lot module it's really nice that you have a record of everything that happens in Drupal in your database because they are just in the top on the reports right and also it's cost you a database right which are inherently uncashable in costing you some performance if you have high availability stack like I create cloud enterprise that needs to be replicated as well will cost you more server resources if you can just send that to a syslog demon service handle logs send that to that low level system and get rid of it to a file system and you're done, save you a lot of performance keep an eye on table sizes we regularly have clients that exceed sane amounts of table records there's a colleague of mine laughing a lot about the client that we just had we won't name them but they literally have a zillion records in a web form which they insist contains really vital data well, export it and clean up the database or literally have a client that has 42 million records of a field revision table of a commerce site they only should need a handful of records, not 42 million clean that up, take a look at those sizes and have somebody who's more savvy on database to help you out if you're not the expert on that check out your indexes sometimes you see a slope running query that can really be benefited from just adding a few more indexes here and there which we will show you views is really nice you can click yourself a query because that's in essence what it is it's a query builder everything that you do in views ends up being translated as a query to your database if you combine 15 tables from 5 different content types and then make them reference everything in between them you're going to have a slope query on your hands sometimes it's really nice for prototyping you can show what you need to a client, is this what you need and then you go to your SQL savvy colleague or somebody else out there who can rewrite that query in a more performant version that you can at least scale and spend expensive server resources on something many of these other modules panels, paragraphs paragraphs is a big one we've seen a lot of problems with that one as well so yeah check your show query a lot and see what's going on there the Veld module also has some nice tools to help you see what's going on which accrues to your database actually better as well can you really make sure we didn't mention them files, in the end it's all files or at least something in your model can always be perceived as a file even though it's actually not limit the number of files I many times see people using I've had a client that literally had over 50 javascript files inside something's wrong there Dripal itself is a nice mechanism where you aggregate your javascript so they all get compacted with one file instead of 50 with some performance with that check that out also try to avoid duplication, sometimes you see I've seen I had a client that uses 5 different versions of jQuery on the same side why? because there were 5 developers who preferred their own version of jQuery or they had a module that depended on one and then a module that depended on another and they just added it all you're wasting bandwidth and browser resources and all so try to squeeze that into one still, you know, tune your images I sometimes see post stamp size pictures somewhere in a footer that are 3 megabytes large because that's the pixel format that's running out of these modern digital cameras nowadays resize it to a more sensible way Dripal can help you with that if you upload it directly to any team directory you don't have that option there's so many other things I could talk for many hours more I literally have 3 minutes now so maybe 5 I'm going to extend it a little bit use drush for anything that you can use drush with, if you don't know what drush is find out what drush is the user release for cron Dripal has its own cron mechanism where it really tries to squeeze all the repetitive scheduled tasks at the end of a normal front-line request so if you happen to be the poor boss that hits your website just after these things were indicated as needing some handling your site is going to slow your process is going to take a lot more time to complete it's going to be really inefficient because there's some really maintenance tasks happening as a front-line request that you can really do much more efficiently system tasks on the level executing drush cron that's way more efficient disabled UI modules if somebody needs huge UI and a production site you're doing something wrong there's all kinds of presentation on how you can leverage the features module or any other widely known Ctools based module to store your changes in views and code so you should not be having views UI is the largest module in Dripal when it comes to code footprint PHP caches all kinds of memory gets polluted by this disabled is the easiest way to save some memory avoid expensive 404 there's a module out there called search 404 that will literally go to a search engine and search every wrong entry every URL that it cannot find it's one way to kill performance and there's a few more and faster check out PHP 7 it's really nice keep calm whenever you have a performance problem try to keep a cool hand and see what's really going on instead of making arguments with your sys admin or your hosting provider and try to work together it's not his fault or their fault or anybody's fault it's a problem that we all need to fix it's a problem I don't pretend to know everything about performance so do you have some answers for things that I haven't mentioned instead of you asking questions to me and then I ask you do you have some recommendations for the rest of the audience not really yeah, Anton knows him he knows a lot it's a new capability for continuous storage support actually the last night we were in the US so it's about rendering a race and caching for rendering a race in Drupal 8 it's turned on when you walk and it gives more power and more profound but you should take care about cached text and cached keys and take care of and carefully cross the ones that you look incorrect it's much more powerful great recommendation anybody else right final tips don't stop learning everything that I said here will be obsolete in a few years there's new technology coming along if you know somebody else try to have a presentation like I'm trying to do here educate other people meet ups you can meet some people there I'm a girl there Drupal Khan London in 2011 there's nice people around here alright thank you