 So welcome everybody and a very warm welcome to all of you. This is a backup session. So if you expected the person from Akamai, I'm sorry, I'm not that person. But hopefully our talks will be pretty similar in what we are dealing with. I've read the session description of the original talk and it was about improving performance all across the stack. And that's also what my presentation, four times high performance for Drupal step-by-step is about. I'm Fabian Franz, aka Fabian X. I work for Techman's consulting as a senior performance engineer. And I just got recently appointed to be a Drupal seven core maintainer. So let's start four times high performance for Drupal step-by-step. Boom. Gisimo, Gisimo. Sorry, no. What, the side slow? I can't, look, I'm a Drupal car. I really can't fix a problem right now. Okay, just kidding. But it happens to the best of you all. Your boss is calling right in the moment when you're holding a session. And there's a little thing. This is a repeat session, but it was updated from LA when it was last shown. So there, everybody will learn something unless you're a PHP developer, then maybe not. But any PHP developer here? Okay, so the last time I did that session, I also did that joke with the telephone. It turned out that if I hadn't had my telephone on flight mode, I would have indeed got a call kind of at exact that time because the client had indeed a critical problem. So it was kind of funny. So your boss is calling. It happens to the best of us, especially during DrupalCon, as I explained, or during elections. The site goes down, the site is slow, grab a touch and make it grow tutorial. But first, let's start with a little story. So, where's the power of Drupal? I hate Drupal. I hate Drupal. And it always overloads the database. Sometimes the Lord reached 200 and it never reached it before. I enabled Core Cache and the server got down again the next day. Yeah. It's a true story. There's a link, you can all follow it. My site is so slow, help. And I think it's a really, really sad story. And that was the one story that motivated me to say, hey, I'm gonna wanna speak about performance. I wanna go show the community how everybody can have a performant and fast site. Because I don't want that to happen anymore. And so there's a real need for high performance Drupal. Faster sites earn more money. Faster sites get obviously ranked higher by Google. And in the original session descriptions, I can maybe even say something like, how to lose 900 million in four seconds or something like that. So obviously there's a lot of things. Visitors love fast sites. I do too. If I'm clicking on a site and I'm like waiting, waiting. That's not a nice experience. Or you are finally mentioned in the media, your product is really going off. You are everywhere and then your site goes down and no one can see what you've brought to the world. That's not good. That shouldn't be happening. But the question is, how do I get such a blazingly fast site? How do I do that? And let's start with some ways. How do you could do it wrong? Okay. I've now tweaked my sauerkraut settings, but the site is still slow. What sauerkraut settings do I need to tweak so that it's as fast as x, y, that, dot com? In this, and that's also almost literally opposed from groups.drupal.org because it happens that people are just trying to tweak something out of some part of the system without understanding. And I've set up 10 slave DB servers, but once I test the site, it is still so slow. Why? So I'm really knowledgeable. I've set up NGNX with advanced ag varnish combined with entity cache and views raw cache. Still, the performance remains the same. What am I doing wrong? Yeah, have you set up memcache as you considered that? Oh, what? Okay. Or the last thing, I've set up static page caching for all the pages, the high traffic they can come. So what could possibly go wrong? Everything. Because the site went down on that day. Actually, that's also a true story and it was pretty scary because I was logging into the server as it was going down. It was like this movie feeling, you know? You are logging into the server, you're typing, get slower and slower and slower. And you're trying to type Apache restart and then it died. And we come a little later, the reason for why that was, but Google Analytics was at fault because the page caching obviously caches per URL. So Google Analytics was happily from the big media campaign, giving a unique URL to everything. So the static site caching in the end did exactly nothing. So we all wish very, very hard that we had the magic pill. Just one pill added and the site is fast. But optimization is a process, not a pill because as we explained already, there's four common ways to fail. You could, for example, try to optimize one part to death by neglecting all the others. So if you build the house on one pillar, it'll not hold long. Or you could be optimizing without knowing where the pain is. And you wanna hold an image to the ball. So you're putting it, now you put a nail in it and then it goes like this. But the problem is you put another nail in here and another and another and another and it still goes like this because that's not enough. You really need to put nails everywhere so that it will hold. And that's a good analogy. And there's also the thing that sometimes there's people who try to optimize things that already other people have tried and failed. So everyone is like, hey, I have this great idea. We could just add this layer and this layer and that and it will all work and it's nice and clean, et cetera. But others might have tried that way already and failed and you might in the end even lose data with it because you didn't understand the problem good enough. So there's a question of do you want to reinvent the wheel or do you want to stand on the shoulder of guidance? And then obviously you really need to law test. There's nowadays a lot of tools available both proprietary and open source. Are we not going into detail on that but you'll find something with Google and when you have a big site launch ensure you are law testing your site. This is so crucial. And please don't just test the homepage but test what you expect your users to do. So what I've seen before is there was a shop and there were law testing their page. Hey, everything is great. It will come. And then the customers were doing something really strange. They were actually buying and ordering things. So but that pass wasn't tested. So the server wasn't made for that Lord in that case. So really you have to optimize the things and test it because when you are featured by big news com your server goes down. That's not a good scenario. So just to recap that again you could optimize one part to desk. You could optimize just random parts without understanding the problem. You could just use a news bus word of the block and just optimize with that like whatever is in vogue right now or you could optimize without testing. But there are a lot of ways to fail. That is also complicated. Is there nothing I can do to make this easier and have a fast site? There's here's the answer. Higher performance consultant. Higher performance consultant. Now Cal now in this second 0 800 Drupal performance and Android blazingly fast sites. So that's the answer. Now now performance is really difficult to get right on but you should hire a performance consulting. Just remember that number are any questions? 5K for basic 10K for advanced. Just kidding you got me. Hiring a performance consulting can be really useful at times but even more useful is learning and spreading the knowledge. So and that's where the step by step approach comes in. Let's walk the path of our ancestors and stand on the shoulder of guidance. Your mission. Loading your mission. The mission. It's Drupal 7 8 site. It has several performance problems, real life problems. So let's meet some friends of mine. I'm very fond of them so I hope you'll like them too. And let's help them in their need. There's D dot pages and I feel slow and sluggish and really big in a way and they're totally unhappy. This is so heavy Lord. This is so much to be here. This is so just too much. And there's Mrs. MySQL and she is exhausted and needs a timeout. I just need a select break. I missed a patch she is sweating under all the load. I give 100% all the time but this is just too much. A Mr. Code is buggy and real troublemaker. Yeah. So your mission is right there on the screen. The Drupal pages feel slow and unhappy. Mrs. MySQL is exhausted and needs a timeout. Mr. Apache is sweating under the load. And Mr. Code is buggy and the troublemaker. So your task, investigate and fix. Let's go. First is server performance. Measuring server performance. The system load is 4.14. The page load time is 20 seconds and the Apache load is 100%. Who has experienced that? Oh, there, okay. Even more than expected. How to measure performance on server and it's easy and we're using that, it's top. You lock into a server, you put in top and you see the server load. It's that simple. And even though there's lots of advanced tools available nowadays, both preparatory open source, monitoring tools, reporting tools. But if you wanna know if the server is sweating under the PHP processes. And it's a problem I'll be explaining a little later. We actually debugged it with top because with top we could directly say, oh, there's lots more load on the server without not much more requests. Then there's a little handy drush command for page generation time of any page. For those of you still using this Drupal 7. Just kidding. That will be still around for a while so that's still handy. But why would you do that? Why would you run a drush command in production? Because there's sometimes problems that show only up on production, that you never see on your staging side and then you really need to lock into production and you need to debug it on production. And then the simplest is to ensure that you're not kinda going into the flow or having to add lots of debug code that could affect your real users. What you're doing is you're doing that with drush and you're just trying to get into the path and you're measuring it. It's a very simple way and I've found problems with that already. Or for example, you have a little task of figuring out which cron drop is slow. You know cron is taking too long, it's timing out, you get errors, but which one is it? And then you just write a little drush command for yourself and you say for each module implements cron do that and then you output it and you start a little timer before and after and then you can see exactly, wow, it's a patchy solar that's taking too long and the reason is a network problem, might be. So now we know that there is a problem or several, how do we solve them? So the four shoulders of the guides. Because while I have said that you always should be really, really, really working on your pain points first, just remember the paper or falling down, there's a stack and it's a performance stack that many, many high performance sites use. And that stack is press flow or in general just good code. Good code is so valuable for performance. Then there's APC and OpCache, MamCache or Redis and some new kits and one is NGX and a CGN. And oh, PHP, FPM, what are you doing here? I'm new here. So before I would say what PHP, it was nice with you, but I think it's time we all switched to PHP, FPM. It had taken a long time until it was most stable but the time has been reached now. Overall, we are seeing better performance with PHP, FPM and there's one advantage that is very, very important. With PHP, FPM and if everyone was there, we could rely much more on that. You can do work after the request has finished. For example, in Drupal 8, there's a pure man's cron if you don't configure any cron in your server, which runs after a configurable vial. And in Drupal 8, this happens after the request has been sent to the user. The nice and shiny L cache that we see later is also doing work after the request has been sent to the user. So all of that is happening, no user is affected. They have already their site and are happy and we can still do work on server. We can do many, many cool things. We can regenerate caches. We can do invalid caches out but that only everything works really, really good for the user that they're really getting the document ready event and everything if you use PHP, FPM. And there's another one, big pipe and streaming. Yeah, sorry, big pipe. You've already been handled yesterday. If you missed my talk yesterday about Stream Your Way to Success, it's online already. You can watch it or any of the other talks. Oh, there's another new one and that's PHP 7. That's also new on the block. We'll be talking about that in a moment. So how can those help me to get a fast site? Pressflow was only really relevant for Drupal 6 sites. Anyone still using Drupal 6? Two, three people. Because Drupal 7 already includes pressflow patches and approaches and as a Drupal 7 maintainer, I can tell you I'm more than happy to accept performance patches and getting those in as long as they're in 8-1. That's our backpot policy, not to be discussed. And Drupal 8 has performance best practices all around. So there's also something like an unofficial pressflow like community based by the groups of Drupal or high performance group. There's like a Vkey where all the collected performance patches that are relevant for Drupal 7 have not been committed. I'm not a longer core maintainer so wasn't really a chance to work on that yet. But in Drupal 8, all is committed already. I'm not aware of any patches that people are frequently applying to the distributions that are improving performance in a lot and that are not committed. So PHP 7, it's up to 50% faster. Sometimes people are seeing 60 to 70% faster. Drupal 8 supports PHP 7 since 800 out of the box. And Drupal 7, and I'm just gonna say this now, supports PHP 7 really since 750. We have all our tests passing on PHP 7. There's one sorting issue where PHP 7 uses a stable sort and PHP 5 uses a different sorting and we are still figuring out how to do that, but it's an edge case and it might happen on your sites, might not, it's just something to look out for if suddenly your comments are above your form, even though you had it differently, then you've probably run into that bug. But besides that, there's nothing now. So really just start using it and start transforming your stack to it. Start with it, for example, in development, start developing sites, then put your test server, then your staging server and then once you are happy and you see everything's working great, put it to production. PHP 5.6 will be end of life just this year already and the long-time support, which means security fixes will be to 2018. So is PHP 7 versus seriously? It's really, really, really worth it. So this is admin performance on a Drupal 8 site. This image is from Josh Koenig from Pentagon from whose blog post I've borrowed it. But there's the source. So as you can see, we really are seeing, like you can literally see a 50% reduction in just the PHP time and database and WebExternal is the same in this example. And PHP 7, with PHP 4.25, it was very slow. 5.5 until this was supported, that took a long time. But PHP 7, suddenly, most hosts are already supported because it's just that much better. And that's a little fun fact you might or might not now. Drupal 8, and especially my involvement in digging deeper and deeper, was a reason why PHP 7.0 release was delayed by two weeks because we found a critical bug in the garbage collector which was happening under very, but it happened in our test suite and then it was fixed and the view had one less bug in PHP 7 and a nice and shiny passing test suite on Drupal 8. Then there's APC. APC really is only important if you're using something you shouldn't be using, which is PHP 5.4 or God beware, 5.3 or 5.2. This Dalun Ubuntu LTS version, which Drupal 7 technically depends on where we say in Drupal 7, we still support 5.2 even as a PHP version. But if you're using one of those older versions, you really want an APC. But for everything new, you just want OpCache. It's really highly recommended. It's on by default since PHP 5.5. In PHP 7, it gets even more useful because it can persistently store all the loaded files on disk. So you have like a backing store, you never have the code cache problems and it speeds up the PHP execution by caching pre-compiled PHP objects because as PHP is interpreted, just passing that all is different, but it directly stores the virtual machine code and just loads that and that's just so much faster. So OpCache, whoa, if you wanna know, is it worth it? Should I really doing that? And yes, it is. It saves around 400, 500 millisecond requests. It saves 100 milliseconds and it saves around 20 megabyte in memory because if you have to compile that everything, it's not only slow, but it's also expensive in memory. And in Drupal 8, you don't want that without OpCache. What can go wrong with OpCache? And that's one of the things probably almost no one knows yet. OpCache reset is buggy. You might think you have your OpCache and now you deploy something new and now you wanna reset it so that you can ensure that everyone gets a fresh code. But if you call that or if it's called if your memory is exhausted or your key name space, then there's a little bug because OpCache is actually disabled when you call that if it runs into a race condition. The reason is pretty simple. In PHP, there was something that wanted to log a warning message that it had to kill some of the process that said we're still using an OpCache log. And unfortunately, they used an error and the error was bailing out so it permanently got stuck in that state. And if you then didn't restart PHP FPM or mod PHP, then your OpCache would permanently be broken and that actually happened to us. But also OpCache reset, be aware of once you are restarting it, it gets disabled and that can take up to two minutes. It's configurable but default is two minutes. So for two minutes, your site is running without OpCache and that could put a huge spike on it. So just be aware. And so size it properly because if it's full, it will automatically trigger restart. Oh yeah, and all release PHP versions are buggy but the next upcoming PHP 5.6 and 7 will have some fixes. You can use a PHP FPM graceful restart and there's a blog post coming up at tech1consulting.com by one of our infrastructure engineers how to do that really cleverly with system D. So look at the stats. OpCache going offline can lead to huge spikes. That's a reassight that really happened last week because why we had the fix in the newer PHP version we couldn't run it obviously because Federa hasn't released it yet. So we were gracefully restarting PHP FPM but there OpCache ran out of memory due to various reasons. And even before it was already not running as nice but then there was this huge spike when it ran out of memory OpCache was completely disabled until the alerting system caught up and we got a notification and we immediately restarted PHP FPM and then the site was slowing, was going smooth again. So really be aware of that. Then there's memcache redis. It replaces the caching in the MySQL database. It's a key value store in main memory. It needs a demon installed so there's additional infrastructure. It's very fast. So what does get you? It's way less load on the database. There's overall faster caches and load on the database for caches can be problematic especially for one reason because you can get a query contention at the beginning because it tries to cache all those cache things and then you frequently write and read. Then it can lock other things out. And memcache is pretty simple to scale out because you have a distributed key value storage. In redis you have like a replication model which isn't as simple. There's also a proxy which you can use to do something similar to what memcache does. But there's a new kid on the blog who has seen the alcache presentation. Okay, few people but not everyone. There is a new module called alcache. It uses a key value store within PHP called APCU which you get automatically if you use APC for PHP 5.6 and 7 you have to install the extension but it's well supported. It's kind of done by PHP maintainers themselves so it's good support, less bugs and used by Drupal 8 also out of the box if it's available. That's even faster than memcache. As a very simple, it just have a transaction lock and a consistent one. But the big advantage is you don't need an additional service so if you don't have a lot of infrastructure guys that can set up memcache or whatever, you don't need the extension that for PHP 7 isn't even stable already yet. And for redis you have something stable but then you have to configure redis and then you have to deal with failover. And if it's on another box you might saturate the network or another container so that's a little problem but with lcache you just need the database and APCU and presentation of that is online already. I highly recommend it even if it's advanced level if you just flip through the slides or go through that that's something really cool coming up. There's also the super cache module. It's similar to lcache and the chain files that's in core. It's especially optimized for write performance and cache tags but it might have race conditions. And then there's varnish. Varnish is really like a shield for your web server. It's crucial for high throughput of anonymous traffic and hopefully soon authenticate traffic working hard on that. You serve the response just from memory and it's like here's your Apache and the shield thing works like this. You have like thousands of requests coming in and they are all for the homepage. And there's a cache miss so the homepage is not yet in the cache. So varnish is just sending one request to the backend getting the homepage back and then all of those thousands get the homepage and all requests afterwards directly get served by varnish. So even though that is an additional demon very, very highly recommend is that's not part of your stack or ng and xcaching added it's so verset much more verset than Apache and static files in that. It sounds pretty complicated actually it was in the days of triple six in the days of triple seven and eight it's really just you use the best practice configuration either from lullabot or for kitchens we should upload our own soon too. You plug that into your varnish and you're good to go. Varnish five has been recently released. I'm not sure but there shouldn't be many changes in that so might need some little tweaking but I'm sure someone will soon upload one for five too. So what does it get you? It gets you really, really fast response times and coming a little later to that but if you can't set up varnish there's an easier solution for you. You can for example use fastly or Cloudflare or other CDNs and just put your whole side behind the CDN that's kind of where most of the things are moving to that we are going away from localized varnish configurations but to globalized by for example using fastly where you can also upload your custom VCL on request and do lots of cool and interesting things and that's less for the beginners that are here but maybe your staff might have some interesting ideas of how to use that. So that's another possibility if you can install varnish at least ensure you're using a good CDN which is not just caching your static assets which was kind of the best practice before but really everything of your side. Your mission, update. The anonymous pages. We are blazingly fast, still big but quite happy. Mrs. Meiskerl, well I have less to do now but if I have it is still too much especially those authenticated users. Mr. Apache, I have much less to do but when those authenticated user come I still sweat and I hate those anonymous UGM requests. So that would be the quick fix for the Google Analytics problem. You just strip it out. There's a little catch with that. If your site is doing a redirect you are actually losing information with that. What you can however do, I just recently learned that is you can kind of put it into a special variable in the request header and then if you get back a redirect response like a 3.0.2, 3.0.1, you just put it back into the URL. So it is a little tricky but it's the only way to properly support that and I really highly recommend adding that to any of the best practice VCRs because and most bigger hosters like Pantheon already have something like that because it can bring your site down because all the advantage caching all those things is just for nothing. So even if you are using fastly you definitely would want a rule like that in there. The alternative is and that won't work with redirect either to configure Google Analytics to just send pound instead of with a question mark. So but then if you have a redirect it also gets lost. So client performance, measuring client performance. You have a page load size of 300 kilobyte page load time of 20 seconds. How do you measure performance on the client? The easiest is you use a Google Chrome developer toolbar there's a network tab and if you install the page speed extension also page speed tab that will give you lots of information. Then there's webpagetest.org which for every performance audit I suggest to at least use once. That means once for the homepage once for the most important note pages, et cetera and ensure that your waterfall is looking good. If you're interested there's currently a very interesting survey on webpagetest.org you can participate in where you can look at the perceived performance of pages and can see which one is faster. It's a fun little thing to do and you get an idea of how it feels then you have to wait for things. Webpagetest.org is also giving you a video for your own side of how it would look for a user that hasn't logged in that before. So it's pretty cool and standard in that. So but why are those pages so big? You need to compression of CSS and JavaScript and that's very easy to set up. In Drupal 7 Core you still have to do that manually in Drupal 8 Quartz enabled by default. And you really need to check that before go live because the users will thank you for it. You need more to rewrite and more headers for that to work properly in Drupal 7 and 8. It can also be done in Apache with for example more deflight but it could put high load on your server because it needs to compress everything so you really want to combine that response. Then we obviously want to minimize your CSS and JavaScript source files. And then there's the Advanced Act module for Drupal 7 and probably Drupal 8 in beta now. There's way less aggregates for that really nice module but we had some clients we couldn't use it on because it had side effects. There's alternatives to Advanced Act that's AgriCache which hopefully goes into Core for Drupal 8. There's the node so if anyone is a Drupal 8 developer that's the node to help on this and then there's a simple aggregation module and you know it happens. I've seen so many modules and then one of our frontend developers came along and said hey I've already written this module since three years, John Alban in this case. Simple aggregation was like never heard of it and they're like wow it's pretty cool because it's a very low risk module to reduce your aggregates from, I think we had 12 on the page and then it was four. And combined with AgriCache you can also improve the performance so they're not mutually exclusive but can be combined. You also want to set proper caching header and fortunately Drupal 7 and 8 just setting this headers for you already you just need to adjust the numbers if you want. Unless you use Akamai in that case you really want to set some edge control headers. So what did we achieve so far? We have only four HTTP requests, much faster page flow time. Your mission, update. Enomeo's pages, we are blazingly fast, really slick and really, really happy. Really, really happy. So additional techniques is to use a content delivery network. It caches files close to the user's location. They're challenges but that's in other talks of if you want to do that with China. It's useful for images, JavaScript, CSS files. So CDN module just got released. The new, I think either beta or a C version of CDN module for Drupal 8, for Drupal 7, it's stable for ages. It's a no-brainer to put it on. You can use it together with, for example, AWS and it just works. And as I said before, fastly cloud for, put your whole site behind CDN and with Drupal 8 and that's in other talks of me and Wim if you want to know more. It's nicely integrated with a cache tech system of Drupal 8. Then there's AJAX PJAX that you can use for pages and image galleries but it needs configuration for Drupal 7 and for Drupal 8, there's refresh less. It only builds the content you need but it works out of the box. Little quick tip, how to fix slow JavaScript. If you have like an unresponsive script or unloading of the page, there's a very quick workaround you can do just wrap the code in a set timeout and do it after the page has loaded, the user is happy, especially if it's not critical. Module performance, measuring module performance. For example, in our sample, the bootstrap would take 240 milliseconds but now for Drupal 7, the menu active handler would take six seconds. The memory usage would be really high. You really want to find out how that's happening and how would you measure such module performance? You would use the XHPROV PHP extension, integration for example via XHPROV module or via my own GitHub module. Okay, Keynote likes to, gonna real quick go into an XHPROV that you know how that looks. This is on Drupal 8 and there's obviously a performance problem because it takes seven seconds. Memory's okay pretty much. So we're taking a look and you can obviously start here and you can go in and in and in and in and in and we're probably still being tomorrow here. So that's not what we're gonna do but we wanna take a look at the numbers and slowly going down and here's a huge gap and now we take a look at where this is. Oh, developer has forgot to sleep six in there. Happens all the time. Actually it happened to me when I was preparing something because I wanted to show really cool demo and needed something to be slow and therefore got it and was trying another screen cause was like, why is it so slow? What happened to it? So yeah, it can happen. If you need to run it on production and you are for example allowed to install the XHPROV extension but you're not allowed to enable XHPROV module or do something else and you really don't wanna have XHPROV enabled all the time. There's a little kit I've wrote which is called XHPROV kit and you just download it and install it and then you have like a index perf.php and you do just like well equal slash user two and then Lord said you are for you. Yeah, and we'll see the sleeper still there so we have to take away six seconds and then at the bottom here's our profiler output and then we got a new profiling. This is very, very helpful for production deployment because often adding a little script is okay but really changing database module installation is not especially because it could make performance problems go worse or by clearing all the caches it could also make performance problem you were trying to debug away. So you look at it and it's a scan. So this is a very unobtrusive way to do that and it's called XHPROV and it's easier than ever to use this triple eight because before you need to set up something and now you just install it call the setup function and then it works. So let's restart keynote which really didn't like me going to that thing and find where we had been. That's where we had been. Good. So for Drupal 8 you can use a web profiler module for Drupal 7 there's a very handy newly released block timer module and if you want to get really, really truly awesome insights into your caches there's a Heisen cache module which provides you a full framework of getting all the information of what your caches are doing. Then there's some common pitfalls, variable set on each page request and it can bring your DB server to its knees. I've seen that happen on a very, very big and important site in production and features was to blame in the end because we disabled the module that was doing the variable set and then features were somehow triggering a rebuild and the module was back and so suddenly it happened again because that module was doing a variable set and hook in it and that's something you really shouldn't be doing. If you want to bring a set down that's somehow the simplest way. So generally try to avoid writes doing page request because every write is something the database cannot scale you cannot push it it really needs to go to the master database. It can bring all your DB server to its knees even if you say, oh, there's one little write of counting the node statistics that won't hurt, it will because in the end, if it happens one time not a big deal if it happens a hundred times can be a very big deal. Then obviously anonymous session set for saving simple data like if you have a low bandwidth flag or you have like country specific saying or whatever, which is really just needed for the front end down put it in session use proper cookies instead ensure that those cookies are readable by the JavaScript, try to do Ajax request for it really avoid opening sessions as much as possible because it disables all your anonymous caching. If you have a shopping cart you probably need a session, but even there you can have things like ignore that session for most pages and just having on the cart and then have a little counter that's just the amount of product the user has added and you still have page cache working counter is read by JavaScript and all pages are nice and clean and shiny and the cart is the current cart content. There's lots of things to optimize it. Having installed way too many modules reverse exit was the worst in Drupal 8 is no longer that much a problem. Drupal 8 we just have a little too many classes maybe. Then there's a little story for views and open layers that could exceed your memory it says a little module for that. Then you use block caching, render caching like my render cache module to improve the performance. There's a cool core page coming up I forgot to put the note in here but explore how to back port render caching system of Drupal 8 to Drupal 7 as the title and it makes block cache automatically work out of the box with all assets Drupal 8, JS, CS, whatever. No more problems can be just enabled. It will hopefully, hopefully, hopefully if you all come to spend on Friday and fix that issue for me I'll be in 751. Use a block cache auto module then you can configure for every block how it should be cached. Set up views caching, set up panels caching, set up displays caching. Click those checkbox and see what is acceptable for your users. Sometimes 10 minutes is acceptable that your content is not okay. Sometimes six hours is and that can make a huge, huge difference in that. Sometimes you say just views has a very nice thing where you have an output and results cache which was broken but it's fixed now. So you need to use a dev version of the newest views. You can set up something where you are looking at views and you say I wanna cache the output for just a short time like 10 minutes. But sorry, I wanna cache the output for six hours but if my results change from the database then I wanna get fresh results and that's very nice combination of that because the output is actually depending on the results returned. So if there's something new coming to the list that just box. Dynamic page cache, it's enabled out of the box but ensure it's effective. I've seen a site that still had 700 milliseconds even though dynamic cache cache was enabled. Use a placeholder for your dynamic things that are making that impossible especially if it's in the main content. Drupal 7 OSCache, it needs to be configured but it's much easier to use now but don't split it too much. Head is hyped with 11 AJAX requests every time it brought it down. It was using AJAX even for blocks that could have been perfectly cached with a page. So really, really only do it for the dynamic parts. So we found the bad code, removed it, the page is much faster now. Your mission, update. Mrs. MySQL, she's almost happy. She feels still kind of slow sometimes. Apache is happy, the D.pages is happy. So that's cool. Database performance, measuring the MySQL performance. Slow SQL series, it takes 10 seconds. Also recently happened to me. Use per corners MySQL slow query log analyzer. You'll find the problems much faster that way. We had a problem on the side, reproduction type, big client. And there was this MySQL problem, slow query and we didn't know why it was slow. I got the slow query log from the server, ran this little tool on it and immediately showed me this is a problem. I was really just literally in seconds I could see it's missing an index. It was originally forgotten in the build because it was a new query added later after it was originally built. And then this was not taken care of. I had the index and it was fast ever since. And able to slow query log in your database for six and I'm just having that on the slide because I'm still hoping there will be a seven or eight version was a DB tuner module. There's MySQL tuner script for seven X and explain your queries. If you're using proprietary tools like New Relic or whatever, you also always have your queries there and you can directly get an explanation of what's happening. And if you see something like creating temporary tables or no index is used, that's a bad flag. Commentaries use inner DB, be aware of the barrier, mind the barrier. You need to use no barrier equals one for X3, X4 and file systems because a newer Linux can is a bundle that's enabled by default and it's zero. So the barriers on and your MySQL performance will just be so bad. It happened to me and I was like, why is my MySQL so slow? And then I researched and I found that. Just be aware, it needs to be used with a special hardware for production usage so you don't lose data. Useful guides and redhead handbook. Easiest to use XFS file system or ZFS, good improving files for MySQL database has snapshot functionality size appropriately to use case. Explain those queries at the index as necessary. You will see what the query is doing. Ensure you have the right order so that it's going from highest to lowest and then run the explain again and see if it's doing the right thing. So, what did we achieve? No more slow queries. Yeah. Your mission, update. Commercials. How? You know this Drupal thing. It's really cool. It now has even more outside in it and the new block placement UI is really cool. And I heard it makes really good here. Oh, I really need to get that. Okay, best practices. You set up the base performance. You want to have your own high performance stack. If you wanna do hosting yourself, you want to have your own high performance stack. It's not as difficult as you have seen. You need to analyze the pain points first if you're doing performance auditing. Where's the problem? Is it server-based? Is it client-based? Is it the modules? Is it the database? Optimize those pain points. Your mission, update. Mrs. MySQL is happy. Apache is really happy. D.pages, really happy. Wake up, Neo. Mission completed. Questions. Please use the microphone. I was wondering, you mentioned obviously Varnish and Memcache. What tools would you recommend, if any, to see what's happening with Memcache, for example? What is cached? What's it being cached at the moment? And when you have distributed architecture, how to make sure that everything is cleared from Memcache to have a fresh start? Okay, so there are several questions at once. No problem. So the first thing is you want to, and what tools to recommend? For Varnish, there's Varnish NCSA command line tool where you can just live look at the traffic. It's using shared memory. It's unobtrusive to Varnish and it's, you just use it, needs a little, there's tutorials on the net to just see. And then there's Varnish Top where you can see a histogram of what's happening on your side. For Memcache, there's Memcache.php script you could be using. You talk about remote Memcache instance and that's a problem. TechOne has been maintaining a remote Memcache thing for years now, where we were actually synchronizing to Memcache instance across two data centers. But while it worked, you can contact us, we still have the patch, but we never kind of pushed it to the real Memcache module because it was not that much demand. I would probably go with Alcache in that case because that solves your problem already. And then you obviously already have some setup for MySQL to do the replication and ensure the consistency there. And that would solve your problems because then you have one problem less, just a database to Kervis and their solution for that. Next question, please. Look, when you were talking about the aggregation of JavaScript files, CSS files, things like that, with Drupal 8's library management and dependencies where it only adds it to the page when it needs to, is that something we should just turn on and just let aggregation do its thing or should we worry about the granularity and when things get aggregated when they don't? In general, in Drupal 8, it should just work with a library system. But the real problem is we are generating those assets. We are making one user suffer for it. And those users' page requests will be slow while we generate it. So that's why the core issue is going into a direction of way more of what other systems are doing. We're going to a standard Gmail way like that we are doing, include those libraries, exclude those those are already loaded. And then just loading the assets and in aggregate ways is just slash JS, include that libraries and we are done. So that's the direction we are going. In general, Drupal 8 should be doing a better job of setting up the groups and everything. Because we've worked hard on improving that performance part as well. Next question, please. Hi. Is Varnish bad to use with forms on the page? Like a Drupal form? With what? Varnish. With a Drupal form. You mean you have a Drupal form and then you have a Varnish. So yes and no. The thing is obviously you have to have some kind of exploration in your Varnish. So in Drupal 8, the exploration would be working with a cash tax. In that case you would be sending the invalidation request to all Varnish. But usually you don't have a Varnish per VAPAT but you have one central Varnish which is usually also being a load balancer to the VAPATs itself. And using a director pattern for doing so, health checks to put out things that are not working like that. And then for highly redundant Varnish you would just use a standard heartbeat pattern with one machine and static IP file over. Is there a chance that Drupal 8 will have eventually memcasing code already? Because right now it has an APCU casting backend, right? Which is not actually in memory. Or if it is, it's just only per request. Yeah. So APCU at the moment is not just per request but it's just enabled for certain things like cash collectors and things that are very, not much written but instead much read. The more likely scenario is that instead of memcache or Redis going into core directly is that either someone writes an adapter to directly write via PSR6. So then you would have all of those things automatically or we as a caching layer of PSR6. The other possibility that is also very likely that in H3X or H4XL cache will be the standard caching solution. Because even if you don't have APCU and use PHPFPM the model of inserting and deleting at the end of request is faster than the current model core users than the absurd we are currently using for Drupal 7. And while it's an alpha, I will try it out and I also would say just try it out if it works for you because it's a really cool solution. Pension just started putting production sites out for it to our launch by now I think. And they've not seen any data errors in weeks so it's really more like they will be going the L cache route because yeah and maybe a PSR6 adapter. Next question please. If there's no more questions then some more advertising join us for the contribution sprints on Friday. There will be a first time Splinter Workshop for 9 to 12 in room Wicclo 2A. And in this room will be the general sprints have fun with Drupal and please, please, please evaluate my session. Feedback is so valuable and I really wanna improve and I really wanna give you a good time and I hope you all had a good time with the session.