 All right Looks like we're good to go here now, so I'm gonna I'll start up The the first thing that comes to my mind and it kind of left my mind as I sat here waiting for this to come up But I've reminded of two years ago when he was on a year ago when I was at San Francisco in the second day in the morning Dries gets up and he stands in front of everybody and he's just quiet for a moment And he says you're all still here and you're all still very intimidating I kind of feel like that people were saying we'll just imagine them naked and I thought well That's a great way to get me off the stage as quickly as possible a whole bunch of you know Naked nerds is not not my thing apparently so So my presentation is on damn quick Drupal How to make Drupal performance scale like a rock star and I might find yourself warning Well, who's the rock star is the Drupal the rock store and I'm my the rock star the little dudes the rock star That's that's the way it is so you're just aspiring to be as cool as the the guy with the bagpipes But no, it really is that I do believe that Drupal is a rock star. I think that Drupal is an amazing Content management system. It's fast. It's scalable. It does everything I wanted to do Before coming to Drupal. I had built five other content management systems So I kind of I kind of knew all the stuff not to do at that point And I was quite glad to find very little of that in Drupal and we sort of have a thing at I work at aquia And we have a thing where we say you know if you build one or two content management systems And you're good three sort of the hump at three you should be realizing you shouldn't be doing this anymore if you go over three It's a negative so unfortunately. I've I've kind of gone that way, but they hired me anyway So I must do something right So the first thing is kind of you know, why me why am I doing this presentation and why I picked this topic? Well, I've been writing web apps since 2001 I've built CMS's that some of them at their peak power of 1500 websites one of them did automotive websites I've run things called auto malls. Those are kind of like auto trader for for those of you familiar with that They some of them would have 500,000 vehicles in them and you had to return results from a database under 500 milliseconds You could have a query that would be you know querying a database full of cars with maybe as many as 12 different parameters You have to get that result with maybe thousands of results back within half a second Otherwise the same site would just load too slow So I have a lot of experience in tweaking databases and understanding how they work I've built a lot of websites a lot of websites in Drupal I've built websites in Drupal to have to handle things like five posts a second Which when you're running something like five posts a second varnish cannot save you anymore You know you have to actually have Drupal running properly and you have to have a really good stack And I've also you know, I've launched Drupal websites that had came up and then died within 90 seconds because of load So I figure you know, I know what not to do and I've learned how to make that not happen again So that's sort of why why why I wanted to do this and why why I think I can You know give you guys some information to help you out with with building a really performant Drupal website Now I know a lot of you probably think to yourself you look at all these Drupal websites out there and you think like you look at like You know White House you look at maybe aquea hopefully calm Since that's one of the websites I run and you look at a lot of other Drupal websites You're like man, these things are fast. They respond quickly. They perform really well. How come mine doesn't do that? It's like they downloaded this damn quick Drupal distribution and I downloaded molasses Drupal or something like that Like that's the version that I got and I don't know where I got it from It's just I went to Drupal.org and apparently there was a link that I clicked when it was the wrong one So the question is, you know, why are many Drupal websites slow and fail and There's four main reasons why that happens The first one is full page renders. That's when every single time So it makes a request to a page you're forcing Drupal to go out and build every individual block And you're forcing it to go out and figure out, you know If there's URL redirects on links and load the menu system all well theoretically you can't actually do that unless you're doing things really wrong load the menu system from scratch each time and Generate all the HTML from scratch every time you really if you're doing that to all the time if every single page has to do that You're literally looking at some of the neighborhood of 200 to 300 SQL queries per page to load a page Which there's just there's no way that's going to perform well. There's no way that's going to scale The other issue that really causes people a lot of pain is the fact that they're serving dynamic content to anonymous users So you've got you know the front page of your website So you're running a news site and you get you know I don't know 10 users a second coming to that website and for some reason or other you feel that I need to have the latest up-to-date Content for these users so every single one of those people gets a fresh page But they don't need it, you know if you're up front page updates every minute or every five minutes or depending on how busy Your site is every hour even That may be plenty, you know some of those blocks They may not need to be you know every single request that you get a fresh block in there So that's one of the other things it causes a lot of pain Excessive slow and non-optimized database queries. This is the tide for number one with why dribble websites are slow It's you know, it's it's both the good the bane and the boon of Drupal is that you don't really have to know SQL all that well the problem is that a lot of people that have built Some contrib modules and written a lot of their own code for Drupal don't know SQL all that well And if you don't optimize your sequel then you're simply not gonna have a website that runs fast Or you just don't don't use SQL and you might be able to save yourself that way as well. The last one is naughty modules There are naughty modules out there that are doing bad things that are gonna make your website run slow And you have to know what those are you have to you know, look at the issue queues for modules Look at how many sites use them and whatnot and really make some decisions About about whether or not you want to use modules, but there's one thing There's one thing that is the answer to pretty much every single issue that you may have with your Drupal website running Slow and that thing is cash You have to forgive my horrible little picture here I was trying to find a gnome that had cash and all I could find was a geocache gnome. So I figured that was close enough And a lot of people you know I've even even glass I was talking to some folks and they were saying that my Drupal site runs slow So my you know my admins are trying to do this stuff with caching and and they seem to think the caching is a bad thing They seem to think like oh, we couldn't figure out how to do it right So now we've got a cache and the funny thing is a lot of people don't realize is that the people are doing it Right that make their sites really fast their site for fast because they're caching There's not some sort of like secret thing that they're doing well Maybe some of them have a secret thing. There's haven't shared it with me but as far as I know there's no secret thing and I've built a lot of websites and I work with a lot of people that run a lot of really big websites and really comes down to is Is caching is how well you're caching when you're caching is your caching optimized and you don't feel bad that you had to fall Back on caching caching is a good thing In fact, I'm not going to read this because it's a tongue twister But you got a cache and your cash would be in a cache and you should cash that too And if you think about the entire internet is just a big long series of caches your browser caches your DNS entries are cached, you know the BGP routes you go across on the internet or cash There's probably worse proxies in the middle of all that caching. There's a CDN caching There's you know, when you get to the actual web server There's you know, there's things are cached on the disk things are cached in RAM things are cached in databases Everything is cached and the reason why everything is cached Is because stuff is slow if you actually had to load a web page and between you and the web server Nothing was cached. It just would never happen. You would never see that web page load That's how really how slow things actually are without cash They just don't work and of course, this is the obligatory little cat screen Drupal wants cash too Has to have it without cash Drupal wouldn't wouldn't even operate So the question is how does Drupal cache because a lot of you you probably you may think oh I go to the performance page and I see this little checkbox says cash pages for anonymous users or if I'm in Drupal 6 I see the radio drop downs for what type of cash I want to run But that's actually not the only cash that Drupal runs There's actually many many caches that Drupal is running all the time a lot of core modules instantiate caches a lot of Contrib modules instantiate caches and they create these cash tables in your database And if you ever look at the tables, you'll actually see a lot of like cash, you know cash filter cash node The vast majority of them actually all use the same schema to there's a couple that are different but they're they're pretty straightforward and how they do their caching and Successive versions of Drupal have cached more and more all the time in Drupal 5 for example Very little was cached in Drupal 6 They started caching a lot of the module lists and whatnot and in Drupal 7 even a lot of the the hooks like Like the for example your theme registry gets a lot more things get cached in that So the Drupal has to do less and less stuff on the fly Which is why by and large Drupal is actually running faster and faster with the successful successive version now Technically Drupal 7 runs a little bit slower But that's if you start doing a lot of crazy things that all the new modules add to core will allow you to do But really the fact that they've added in a lot of caches helps a lot And they've also done a lot of work and successive versions of Drupal to make it run better with more nodes For example Drupal 6 once you start getting over the 10,000 node mark You're gonna start having a problem with Drupal 7 you can actually get up to 100,000 nodes without any big issues at all So there's a lot of a lot of good things in there One thing of note too is that the things I'm talking about in this presentation the vast majority of them apply to both Drupal 6 and 7 There's a couple things that are specific and I'll call those out But I really wanted to to make it as as broad as possible because I know a lot of people are still running big Drupal 6 websites And they you know a lot of them they probably want them to run faster So how does Drupal use use the cache in the database? Well that uses these cache tables to store data and it loads this file called caching You'll find your includes folder and amongst other things it defines these two functions called cache set and cache get and they take the same order of variables Grab data stick it in your cache get data out of cache provided out. It's pluggable as well So you can actually create your own caching. You're like you know what? I don't like the way the Drupal 1 does this I don't like the fact of storing it in the table like this I've got this better way of doing it you can come up with your own better way of actually storing your cache and you can do it If you use a module like cache router, for example, or if you use the Drupal 7 Object-oriented way of doing it you can actually make it so that different things store in different caches So for example, you could make it so that your your filter cache stores an APC and your node cache stores and memcache or something Like that you can define, you know exactly where each one goes and in fact That's what a lot of a lot of these modules do that give you some performance improvements to cache I've got a couple of them listed there like One's called cache ironically cache router memcache APC These are all modules that install and then you go into your settings dot php file And you say okay for here's my settings some include code for this particular cache module I'm gonna say I want this particular thing to catch here and this thing to catch there Those are those are big improvements. I'm getting into exactly how those work But what I really want to start up by showing you guys is sort of just how triple caches So using the queries it runs show you how you can optimize those queries cause those queries not to run at all and make your website faster in some cases and And get a website so they can serve pages in under a second because that's really the goal You really want so that when when Drupal is done with its HTML on it sends its HTML Back to Apache or nginx or whatever you're using for your web server that it can do it in less than a second If you start going over a second, that's a big red flag You should really never have that happen because you really want your web pages to be loading for your end users in three seconds And most of us know that you know you you design this great website and then you know the marketing guys I know you're out there You have JavaScript includes you want me to put on a website right now I know you do you know They're gonna give you a whole bunch of JS files And they're gonna say we want all these cool images and whatnot before you know it the front page your website has like 80 assets That's got a load after gets that HTML so that HTML needs to be delivered in a second to You know or at least be sent out in a second so that everything else that can happen needs to happen So I did a bunch of testing To try and make that to show you guys how you can improve that and I got the cheapest server I could get my hands on I got a one of rack spaces cloud servers. It costs $10 a month. It's a quad-opter on I don't recall the speed It's got almost no RAM which I thought was great for a test because we'll try and do this on as little RAM as Possible and just running Apache my sequel PHP just whatever you know the Iran sent to us Whatever the you know the the um install gave me and no reverse proxy So that's important to know nothing like varnish or squid is involved in this I really want to just do my tests with Exactly what what the web server and what Drupal we're gonna do I didn't want anything in front caching it So the tools that you really want to use whenever you're doing anything like this. They're pretty straightforward They're not that hard to get your hands on The develop module is key. I'm sure that all of you know what the develop module is and And you're using it not on your production websites But you're using it and if you don't know just don't tell anybody because just pretend You know what the develop module is and use it and then go quickly look it up on Drupal.org You want to use it to determine what your page those times is what your memory consumption is see your queries And also the news versions of develop integrate with a thing called I called xh prof I think it's probably called h prof because I've heard people say that it's this amazing tool that actually graphs out for you and Draws diagrams of all the functions and calls that your pages make and how long everything takes Integrates to the develop module and it's it's pretty impressive We have time at the end. I'll show you guys some screens of what it looks like New relics a third-party service that can be really good for gathering a lot of this data about how well your sites performing It's a for a daemon that runs on your server and then sort of watches what's going on and reports back to a website That gives you a lot of data and of course the good old ones like a patchy benchmark bombards siege jmeter Some paid services system blitz or services that can do a lot of benchmarking for you But for what we're gonna be doing here I'm actually just going to be using just the most basic easy to get your hands on tools We're using the develop module to gather some stats and then we're gonna use a patchy benchmark to see how well things work After we've made some tweaks to a site And just so you guys just for a couple of Terms there's cold cash or warm cash I'll refer to that couple of times you pull your people saying that cold cash Just means there's nothing in cash yet, you know the site hasn't loaded So the cash tables are or you just click the clear cash button on the performance page your cash is empty warm cash Theoretically is when everything is in cash Sometimes it takes a couple of page loads to get everything in cash as well to get your cash warmed up in addition You know things like the patchy actually has a cash my sequel has a cash And that when you sort of fire up my SQL you're actually gonna have a cold cash And you're gonna want to get that warmed up key value stores are things you've probably heard about there are things like APC Cassandra memcash redis All they do is they have a key and a value There are more complex ways to implement them as well, but really that's in their basic state That's what they are and there are also a lot of things called no SQL and there's opcode caches and compilers APC accelerator ion cube xcash is a whole a whole pile of them And what they all do is they compile your PHP in advance so that does not be done the fly every time that's sort of a thing that a Lot of you know a lot of hardcore programmers who've been dealing with other languages They come to PHP like my god You know why can't I actually compile this in advance to see if I've syntax errors and whatnot and it's and if you think about it It's actually kind of crazy every single time you're a patchy you're wherever comes along and says to PHP says hey You're give me this page PHP says okay, let me find the files finds all the files as all the includes Compiles it optimizes it and then hand as it pans it back It does it every single time but the files are the same every single time So there's actually no logical reason to do that and something like APC will actually cause you to stop having to do that APC will compile all your PHP and then store it in memory So it doesn't have to be done every single time and that's that's like a no-brainer Like if you don't have APC running on a web server You're really just you're asking for your web pages to use four times as much memory to load as they normally would you just You have to use APC it's if I was to say that there's just one thing that you could do to make it so your website's more robust That would be it be to run APC and it just you just do a peckle install to get it Or sorry, it's depending on your OS some some of them actually have them as I think yum You can just pull it right down So I want to show you what sort of a cache that looks like and unfortunately that appears to be a little bit out of focus But those big giant blocks over there are actually the stuff that's getting Put into the database when cache set is called and what you probably can't read very well here It's as it executed 330 queries that took seven hundred and I can see better here 775 milliseconds and the page was rendered in three point three millisecond or three point three seconds So that's obviously not that good You wouldn't want a page that took three point three milliseconds just to get out of out the door with Drupal You want that page of course to be you know rendered like said and well under a second So but this isn't this isn't how it normally is because this is when when cache set is being run So the you know all the HTML all these variables are all being plugged into the cache Once the the cache has been has been set you'll see that there's there's a lot less queries We're down to actually 155 queries and they actually all executed in 350 milliseconds and the page was rendered in 1.5 Seconds, but you can still see all those pesky cache get calls in there And actually if I was to show you just roll down and show you the whole page that this is the develop module for those of You don't haven't used this before showing all the sequel queries that were run You'll see that there's probably about 50 or so cache gets that run on this page Which means one third of all the sequel queries that ran to generate this page where cache gets and you're thinking what's a key value store It's it's a key with a bunch of data attached to it Does that really need why really need to be firing up TCP IP making a connection to my sequel having it check my query Seeing if that data is in cache if not pulling the data out of its cache putting into cache That's just a lot of work just for some of this information. So the thing that you really want to do is You want to figure out ways to get around that now. This is just another another screenshot This is actually after my sequel has done all of its caching on its end And you'll see that the query the times are actually a lot slower before a lot of those cash gets were highlighted in red But now my SQL is actually cached bunch of stuff too. So it's running a lot better, but it's still not great So what we want to do then is we want to use a key value store and I mentioned a couple of them before The bigger ones that you hear most of time are APC or memcache APC aside from being a Add-on that can compile your code also has what's called its user cache and it can actually store variables in memory The really cool thing about APC is that it runs in the exact same memory space as the PHP process So it doesn't have to make a TCP IP connection to get data PHP just says hey give me this data and APC says there it is and it's pretty quick The problem is if you're running your site on more than one web server then the APC can no longer share memory And so if you run if you want to if you're running multiple web servers You can then use something like memcache and you can say here's my memcache server out here And then both servers can connect to it which is really neat actually because that means multiple web heads can actually be generating Cache entries and storing them so that the other web head can then access it And do otherwise if you don't do something like that each web head has to keep generating generating caches And if you think about that that's not ideal because one does all this work to generate this cache And the other one doesn't have access to it and it's got to do all this work to generate cache And you've actually in some respects actually increased the amount of paged amount of time It takes a load of page so if you run multiple web heads you really need to make sure that they are sharing cache If you don't do that you're you're asking for some pain So after adding a key value store in this particular instance I used the cache router module to give myself APC as my cache because I'm just running one web head here It's not a problem and I'm actually down to a hundred and seven queries now And they executed in thirty six milliseconds the entire page was generated and sent out the door in two point One two milliseconds, which is very nice. That means I'm actually you know I'm a fifth of a second now to generate this page and important thing to note too is that this is a bit of a painful page This is a front page of website that's loading 50 nodes with comment counts. It's showing showing attachments. It's I'm running the admin module I've got develop running. I've got a lot of stuff going on here that you that you typically wouldn't even be this this mean to your Website on a regular basis. I'm also not running it as admin. So there's a bunch of access Node access queries are running in here as well, but I think I've got a pretty good result here I'm down to you know down to a hundred hundred queries. It's not horrible. It's pretty fast But I want more so I'm gonna go and check and see if my SQL is actually properly caching now in this particular example here It's not really this is a page out to the Drupal provides if you in Drupal actually I don't know where he's in Drupal 7. I haven't found it yet, but in Drupal 6 if you go to your status page Your site that page it'll show you the my SQL version you're running you click on that link It'll take you this page and if you look on that and you look down at the bottom there And you see query cash queries and cash zero cash hits zero cash inserts zero, you know You're in trouble that means that my SQL which has a very good cash actually is not being used at all Which is which is bad and interestingly enough This is the the result of the default my SQL install for for CentOS the defaults that came down Didn't put anything in there to enable any caching whatsoever. So I Didn't you know you don't want to rely on that in fact one of things that I've talked about a couple of people recently is that you know, there's there's Don't assume that the default settings are good And also there's another thing to keep in mind is there's no one-size-fits-all group of settings for things like a patch Here my SQL or whatnot if there was a one-size-fits-all setting They would just come with that and we'd never have to tweak it We have to tweak it because every server is different every environments different Every website's different the things you're trying to do are all different So I put in just these are just the settings I used on my website when I was doing my optimization I had to keep it pretty small because I only had 256 megs of RAM So I couldn't have a patchy go and chew up, you know all of the RAM and leave nothing left over for PHP to use So I just gave it some sane settings in here And these are you know if you were to pick seven settings that you have to set on your MySQL server You just simply must set these settings. These would be them Well, I guess unless you're not running my is and then you can ignore that one But key buffer size is the key cache so every time you have a table that's got indexes in it You know that key cache is where those indexes get stored if you don't have that set then every single time you run a query My my school's got to go and load the indexes off the hard drive Which isn't really that much of a cache and after a while It's I mean your hard drive will probably cache it for you as well But it's not that well optimized query cache caches the results of queries So if you have two queries that are identical my SQL doesn't go out and say hey I'm gonna go hit the hard drive and and find out what this what the data is gonna be for this query It actually just simply says I ran this query two seconds ago I'm pretty sure the results gonna be the same then as is now unless the table's been changed And it'll just give you that result right there query cache limit just limits the size of the query result That can be in there. I really hope that none of us are running queries that return results greater than two megs On a regular basis at least, you know, you don't want that in the front page of your website table cache Is a pretty neat thing too my SQL actually has the ability to load up all of the tables and just Stick them in RAM and it uses your table cache size to Number determine how many tables it can do without that with at once And if you want to really know how well this is working out for you PHP my admin has a great page shows you all this information Or you can just run the show status command at a mysql prompt and you can see the setting called open tables In fact, I think this page shows it as well Nope, it doesn't show it but so you can but you can find it other ways And if you see that your your mysql is constantly having to open tables That means that these tables are not in cash And it's actually taking a table out of cash putting a new table into cash and then constantly doing that over and over again So you got you actually you that you really need to watch that setting you need to make sure that It's not constantly opening tables and the table cash that you have is good enough Sort buffer size is pretty important If you don't have a buffer for my SQL to do sorts and it's gonna create temporary tables on disk and do your sorts there And that's bad You do not want to have to do that and a great way to see if that's happening is to we'll just jump back a couple of slides here You see a query in here that's horribly slow like it's got like you know those numbers and laughter seeing something It's like 50 80 100 milliseconds just grab that query put the word explain in front of it And then run it at the mysql prompt and it'll actually tell you if it's able to if it's using temporary tables to do sorting Or if it's if it can't find an index or something like that And that's that's incredibly important and that's sort of where I got back to one of things I said at the beginning is that don't assume that everything was done perfectly for you Especially if your site's running slow you want it you need to you need to look at those things you need to Investigate the the queries that are going on and make sure that everything is Properly optimized and then the same thing your smiles and sort buffers just another setting the first night is used by you know Db the second ones used by my as I believe it's possible But one of the rides the other later versions and then the temp table size is the size of temporary tables that mysql Will make in RAM if you make it and if you end up if there's a there's a in the show status I'll actually tell you if it has to curate temporary tables on disk a lot to do to do joins and whatnot So you want to make sure you have those set so again if you if you If you have a server if you have a mysql server and you have not looked at these settings You don't know what they are you need to look at these settings and you need to understand them If you don't do that you simply are gonna have a very hard time making a website that performs well I'm not gonna give you a lot more detail on this If you just look Google like mysql performance You're gonna find like the entire first pages be full of websites to describe these settings and tell you you should Use this much of your machines available memory for this setting in this much for this setting But they're they're absolutely key So after I've done that I have no more slow queries. In fact a lot of these queries that were taking 10 or you know, they were taking They had like double digit numbers all to say here a lot of them are actually down to just like single digit numbers are even lower If I scroll down here, you'll see that none of them are highlighted in red before when on every single screen if I'd scroll down There were still some that were highlighted in red and now my my queries are down to 17 Milliseconds to run all of my queries for my website, which is awesome So now I know that my SQL is no longer a bottleneck on my site So I'm good I can now look at some other things and so one of the things I mentioned before was was APC APC I just I just can't I can't say enough about APC. I love it if I did wasn't already married I'd want to like seriously start taking APC out in some dates So again, like I mentioned before what it does is it's gonna compile all of your all of your PHP code And then it's gonna serve that compiled version It's it's awesome. It has this other really cool setting to one of things that it does is Before it serves that compiled version it goes and checks to make sure your file hasn't changed before it does that So it's like okay file hasn't changed so my compiled version is still good But for the majority of us, you know, we're running using source control. We're not releasing stuff like crazy You know when we when we cut a tag we deploy that to our server that's code's not gonna change It's gonna be the same thing until like, you know next week when we cut our next tag So there's really cool setting called stat zero that you can set or stat and you set it to zero I should say you set that in your apc.ini file and it no longer runs that check So it's a really neat thing to do. You can actually you can actually Load up your website And if that is set to stat zero just going to delete your files and your website will still load because my APC actually has them all catch in memory It doesn't even check the disk anymore, which is great because you know You just you don't want to hit the disc if you can get away with not hitting the disc you want to do it Any other neat things to a Drupal module such as catch router and the APC module and other ones Will actually integrate with APC so that if you were to go and clear cash in Drupal It knows to go and clear the APC cash as well So you don't have to worry about like oh I've got to go and like restart a patchy when I want to do this stuff You just hit the clear cash button in Drupal and you know the the cash ink module that comes with cash router For example just says okay We're using APC and it goes off and makes the call to clear the APC cash So it's pretty sweet The other thing you get with APC is you get this really cool page It gives you all these stats on how much of your your APC cash you're using if it's fragmented It's also got some hits and misses in here So you can see if you're getting good hit rates and good misses and you can optimize and tweak from there on in It also shows all of your stats down below and in addition you can see that's got you can put out You can see that perfectly well up there, but you've got system cash entries and user cash entries So system cash is the opcode cash where it's caching all the pages and then user cash entries is where it's actually Caching like your key value store and you can clear those independently as well So it's pretty neat. I've actually seen that people have made this for memcash as well So you guys use memcash for some of the stuff there's a page like this as you can get from memcash Which is it's pretty awesome So the result of all of these tweaks and tests when it's all said and done is that this page now runs 97 queries Oh, there's another thing I did in the middle in here that I forgot to When I made all my screenshots is that another big table once you eliminate all the caching tables The table is gonna cause you the most pain is the session table because every single time some module decides to store Value in the session it whenever Drupal hits a hook exit it goes out and it says okay Here's all my session stuff and it goes and puts it in the session table for that user And you'll end up with just massive inserts going into the session table And the problem is that especially running my is and what you shouldn't be doing you should be running a no DB Especially if you're running my is and you're locking the table during that insert and whenever user on your website is waiting for this You know the session insert tape insert call to get it done So APC and memcash Both have options where you can take your session table and you can stick that into those caches as well And you're no longer doing those rights to to my skill In fact on those that went down from 107 to 97 queries Which is great, especially considering that we started out at three over 300 queries to load this page And now the page is being sent out the door in 180 milliseconds And our queries are only taking 14 milliseconds. And again, like I said, this is a front page It's got a lot of stuff on it. I'm using a Very slim theme. So obviously if I was to be running some big monstrous theme I would probably see a lot of my numbers double in there But for the purposes of this test, I wanted to show just really what what settings are affecting What kind of sort of core settings there are that you can speed things up and then for a single note If we hit just one node, we'll see that 33 queries 5.87 milliseconds and my speed ironically was a little bit longer But that was probably because something was getting written into cash probably the page She got written into cash and it was 192 milliseconds So the other thing too is you want to see well, how fast is this for anonymous users? So a great tool for that if you guys know has ever used that before is to use get the firebug extension for Firefox and hit the net panel and if you hit the net net panel You can actually see all of the files on your website and how long they take to load And we'll see that our page itself to get out the door with Apache and everything took 299 milliseconds, which is pretty good that means that my browser made a request went out to Apache Apache Talk to PHP got the result back send it back to my browser, and I got it 300 milliseconds, which is good That's what I want and in fact my entire page loaded none under one second Which is what I want except I've made a classic mistake here I forgot to hit aggregation for JS and CSS files So if I do that we'll actually see that I now I'm only making 11 requests to my web server, which is awesome And all of us forget that sometimes it's okay. I do it too So a little bit more on Drupal caching so we've talked a little bit about how Drupal is doing all of this caching Where it's putting it how we can improve our sites by sticking it somewhere else and so you wonder Well, when does Drupal create cache? The answer is all the time, you know, your new module Makes us change to the the variables table. Well, the variables table is cash So you go and you hit the save page on a module Drupal goes out and it clears the the variables Cache entry out of the cache table builds a new one sticks into that cache table You know you may change a menu item. Well that menu caches and update all the time caches are being updated And so the next question is well when does Drupal clear cache and the answer that is all the time Drupal is constantly clearing things out of cache putting new things into cache Now some of the things are kind of interesting here that that I was actually not even fully aware of even up to like a year ago Is that there are things that get cleared out of cache at times you just would not expect? So for example, if you've gone into the performance page and you said Cache blocks or you've just set on Drupal 6 you've set the the caching to default or Drupal 7 you've hit the Clash pages for anonymous users what that actually does is on hook exit Drupal takes all the HTML it just rendered To deliver that page and it sticks it into a cache table so that doesn't have to keep doing that over and over again Which is fantastic. I mean again if we do something like a PC or memcache It didn't stick into a cache table stuck into a key value store up on a server somewhere that's going to save us even more time But if you save a node Drupal calls this function called clack cache clear all and what cache clear all does without any parameters passed to is it Wipes the node in the block caches So you have your like you know your site's being hammered you're like yay It's standing up well everything's going well and one of the editors is like oh crap We got slash dotted and I have this mistake in there so that editor goes they modify that node They hit save and your block caching when your page cache for your site are wiped out and Now the next thousand people that are about to hit your website are all waiting You know maybe six or seven seconds for the first person that hits a page again for the caches to all be rebuilt Which is obviously not good at all The reason of course why Drupal does that is say for example You've got a front page with a bunch of views displaying You know it's a bunch of nodes on it and you've got a list of nodes on the front page And what not maybe a couple of blocks and they may be they've pulled data from a node as well as Drupal doesn't really know Or or you know it's not feasible for it to keep track of exactly what nodes are stored in the front page Which just says if you modify a node I have no idea where data from this node could possibly be called from it anytime So I've got to clear all the caches because chances are data from this node showed up somewhere So that's why we're not all the caches the block in that the node caches So that's why it does that but you can get around this you can save yourself from accidentally stumbling and Calling on this particular issue and what that is is on your performance page There's this little drop down that says minimum cache lifetime and that is your savior You know that thing there that setting wants you to set up something other than zero. It's desperate for you to do It's calling out. It's like give me at least five minutes So whenever we cash clear all it's called it says I'm gonna clear cash for everything that has been that's older than that setting Which is what can really save you? You know when it was from a lot of things if you think about all the content editors doing things on your website every single Time they're saving a node they're clearing the block in a node cache for every single page in your site So give that thing a setting giving it give it at least five minutes and that way things like your front page and whatnot Are gonna always be cashed for five minutes now There's some people say oh my goodness five minutes is a long time for for this page be cashed But keep in mind that's just for anonymous users authenticated users They're still getting a fresh page if you think about if you've got like a news site It's okay for that front page to be cashed for five minutes. It really is I promise you You know no one's gonna cry if that node title that's in that one block over on the side doesn't update for five minutes Or if it is imperative that it does you know go and deliberately hit the clear cash button That will do it don't let fate sort of just have its way with you I would strongly recommend setting that setting to like an hour or even six hours if you can get away with it And just be smart about knowing when to clear cash, you know by hitting the clear all caches button So again, that's an easy win, you know set that setting Set a page cash, you know you may not have that many anonymous users But still set that page cash so that they don't have to so you don't have to be generating You know fresh pages for them all the time and then the last thing is to double-check your headers Make sure that the headers that you're brought that you're sending out to the browsers Don't say things like no cash or don't have a max age Because those are the things that determine whether or not the browser is gonna be able to cash that cash the page or not And if the browser can't catch the page the browser is making a fresh request every single time and you can save yourself from that In Drupal 6 you have to install press float to get the option to have a max age And in or you can just a series of patches you can use as well in Drupal 7 you have that option by default So I'm just gonna show you guys some examples here We saw before that it took 299 milliseconds to get this page out the door But by turning on the Drupal cache the Drupal normal cache in Drupal 6 we drop that down to 79 milliseconds And then by using Drupal aggressive we drop that down to 60 milliseconds Now the difference between the two of those is that Drupal normal will still make a couple of database calls So make sure to check some variables and look for It actually doesn't fire hook in it But it looks for a couple of things you can you can kind of get your get your foot in the door on that one Make some changes Drupal aggressive basically instantiates the database and the first thing it goes off to do And looks to see if it has that page in cash and if it does it gets that page serves it and exits But Drupal aggressive requires you to set a minute a max age to really make use out of it Like I said felt that max age You're not gonna get things like like varnish is gonna be able to cash and whatnot So it's it's pretty key and Drupal 7 Hopefully this gets fixed soon to whoever's responsible for such things There's no option in the interface to set an aggressive cash You actually have to go and make some changes in your settings dot PHP file And if you Google or if you look on Drupal dot org for Drupal 7 aggressive It's a page written by Peter will land and he has the exact instructions on what you need to do in your settings dot PHP file To get an aggressive cash for Drupal 7. I strongly recommend an aggressive cash I can't think of well I could have a couple reasons but they're very minor why you wouldn't want aggressive and even if you're looking there And you're looking in Drupal 6 and you see aggressive and you see all these Modules listed out in red that that are incompatible with aggressive That doesn't mean that those modules just disintegrate and your website falls over something like that It just means that the hooks that they may want to run don't get called when you choose aggressive For an example be the statistics module when you set the aggressive cash The hook that's just the statistics module requires which I believe this hook exit to to gather statistics just doesn't get called It doesn't mean that something your website's gonna break It just means that those modules may not have all the functionality So I mean if you if you think you can get away with with without those modules having full functionality for your anonymous users set aggressive There's there's absolutely no reason not to do that So the next thing up here is Apache and PHP now I'm talking mainly Apache and in fact all my tests were done in Apache because that's the one that we run the most sure There's things like light HDBD and there's engine X and whatnot But the folks that are running those honestly probably already know all this stuff And in addition there's a lot of times where you may not want to run Apache But you have to maybe you need to use like the LDAP module and Apache to do some sort of reverse proxy Or sorry mod proxy And mod off an Apache do some sort of LDAP reverse proxy authentication where you've got to get through your proxy server with storing session Cookies and stuff like that and you've just got to use Apache because they're the only ones that have that So I'm talking Apache here and all my tests were done in Apache and the bit first question with Apache as well Do you run mod PHP or do you run fast CGI? Personally, I would almost always advocate running mod PHP Mod PHP gives you a lot of benefits one is that the Apache workers have already brought P brought PHP up They've got it running anytime Apache workers fires up It's got PHP already running and loading in it whereas fast CGI doesn't necessarily do that now The advantage of the flip side of that is if your website serves a lot of other stuff That's not PHP then then maybe mod PHP's a little bit detriment because Apache fires up and every single worker thread brings up PHP along with it and it serves a gift file and That happens if that happens more often than PHP files then you know, then you're gonna have a problem Although if your web server is serving gobs of non PHP files, you really shouldn't be getting to Apache for that You should be running a CDN or we're running something like varnish and serving all those files for there The other advantage is that if you run plot mod PHP every single Apache process can share memory the peers very or more Specifically the PHP running for the Apache process can share memory So that way if you got like 10 workers going on with with Apache and they're all running mod PHP That means that if this particular one does something and it sticks it say for example into APC's caches This one can grab it as well and pull that data out if you're running FC GI then this one put something into cash. This one has no access to it So in fact everything I said about PHP or about APC speeding up everything and making it wonderful Virtually goes out the door with mod FC GI not entirely because it's still better than having no cash at all But none of these processes can share cash anymore and on the flip in addition to that is that you know Most websites you're probably looking at 96 megs of RAM you want to give to APC to store stuff Well, if you're using FC GI that means every single process is going to use up to 96 megs of RAM to store It's cash, which is maybe you don't have enough memory for that in your server or maybe you didn't even think about that You're thinking okay PHP is only taking you know 50 megs of RAM to load a page I've got you know 500 megs of RAM available PHP Therefore I can have you know X number of processes But you forgot about the fact that APC is in there You know and you've you've enabled caches for that you're running mod PHP You're like adding 40 megs of RAM to every single one of those processes Which can bring your site down if you get hammered in a way that you weren't expecting And that brings us to maximum simultaneous processes. You need to understand those settings I'm gonna get into that in a lot more detail because you can do everything right and just put one number wrong in your patching Configuration file and have your website disintegrate and not even under heavy load in some cases You need to understand the Apache modules. I know it sounds crazy I'm like telling you do something you really don't want to do But look at the Apache modules that are running in the Apache Conf file and then go to the patches website and read up what they do Chances are you don't need half of them But every single one of them spinning stuff up and loading into memory on every single page request and you're never gonna use it And there's just no reason for it pre forked versus worker. I prefer pre fork Just because that way it's already done and also it also it does depend someone your operating system Whether or not you want to run the the forked patchy or if you want to run the the threaded version of patchy Ironically on windows threaded works better and on Linux pre fork works better Which is pretty much what everybody runs and then min servers and spare servers these these two little Numbers that are set in your patchy configuration file most people like ah says eight and five that looks good to me or something like that The thing that those really do is that the say for example You you you have your maximum number of Apache processes set to 20 and your min is set to five and your spare is set to eight That means that you turn on a patchy and it fires up five of those processes and then it says And you get so you get slammed and it fills up all 20 and then what it will do is it'll it'll shut some of them off as They're not being used and it'll drop down and keep eight in there as well Well, the problem is that you want to keep those you want to try to keep a lot more servers run a lot more processes running for Apache you want to have as many children as available as you think you're gonna need At any given time so you need to chances are you to up those numbers because firing up those additional processes expensive If you have five Apache processes running you get ten each one of those additional five it needs to fire up It's like firing up a program. It takes as long well. It takes less time. You know that if you're doing it to know us But it's like it's like starting something up. It's actually got to fire it up It's got a little over the modules process the configuration files and so on and so forth And you really don't want to have to do that and the last one is child lifetime There's this little setting and it says child lifetime And I think the default is set to 10,000 in most installs and what that means that child processes there and it's serving pages And it's firing up, you know But pay PHP and doing all the stuff and they get to 10,000 you're being slammed by the way your website is It gets to a thousand says oh So one thought I must have a memory leak I'll just shut down now and it shuts down and patches like I got to fire another one up and you're doing that Probably at very inopportune times If you don't think you have memory leaks and you've watched Apache and it stays pretty stable And when it shuts off processes the memory consumption goes back down set that to zero And then maybe just restart Apache manually, you know on a certain schedule or just let your ops team if you have guys like that handle that but You really you don't want to set that to something like a thousand Because that means after a thousand requests they're restarting setting the number to a thousand and getting slammed will bring down your website quite likely So you know set that to a really high number or possibly set it to zero and just have those things never Restart automatically just wait for Apache itself to be restarted in it to to determine that So the one of these I touched on briefly here was the maximum simultaneous processes That's really the the most important thing like how many simultaneous requests are you getting how many simultaneous processes Should you be firing up to handle that and if you get those simultaneous processes, you know You'll be firing up to handle that and if you get those numbers wrong like I said, you'll bring your site down So the first thing you need to do to understand that is you need to know well How much time does it take to look for me to load a page and how much memory does it take to load that page? I'm talking in PHP at this point So this is the performance monitoring sub module that comes with develop Like I said, there's a lot of other ways to get these get these numbers as well You can use New Relic as a great tool to but this is something that we just have all available to us You download the module you install it you let it run for a while and we'll see them this particular website This was a small test website the average memory per page is is 11 and it takes 289 milliseconds to load a page so what that tells me is That on my test server that I had with 256 megs of RAM I can assume that I can maybe give allow PHP to have 120 megs of RAM That's probably being a little bit too generous. I probably don't actually have quite that much memory available for it I should also take that number and add to it because that's really that's from hook hook boot to hook exit That's how long That's that's how long it took for those two things to happen But there's some stuff that happens before and after that and there's probably a little bit of time that Apache is spending Dealing with the request before and after that so you know you could be safe You could add 10 to 15 percent of that number which then gives me 333 milliseconds to get the result out the door for the for my page loads on average on this site Now that means that I can have 10 simultaneous processes running So then ideally I will be able to serve 30 pages per second That gives you your number so few or sorry Was that minute yep, yeah, so it's per second. So yeah 30 pages per second So that means this website can serve 30 pages a second, which is actually great Now considering this is a fairly small website and there's not a lot going on that's gonna be okay You're gonna of course come with probably significantly higher numbers on this and a lot of will be due to your theme Believe it or not, that's what's gonna chip a lot of the RAM when it comes to loading your page so You want to know what your what your traffic peak is so free because those numbers I gave you those numbers are Probably gathered a lot of them at times in my website is not really doing anything which means those numbers are all ideal So what you want to do is you actually want to use a tracking system you can use Google Analytics Although that's not gonna help you a lot if you're using page caching Like barnards or something like that performance logging is a great one to use like I showed you can use your web server logs And you want to remind page loads you get during your peak traffic times Say for example your peak traffic time is one in the afternoon You don't want to you want to get like you want to grab the peak So you want to grab like the top 90% from even the top 95% of that peak And you really just want to look at the numbers during that part of the peak You don't want the whole thing because that's gonna skew you you're gonna see better page load times at the bottom And they're gonna skew your numbers you want to basically make sure that your website is gonna perform Perfectly at peak because to be honest when you get slashed on it and 10 million people come to your website Your website falls over that's time your boss is gonna be really pissed They don't care as much for crashes at 2 in the morning for some obscure reason They don't want to crash then so you have to you have to plan for your peaks so You determine how many pages by minute you get during that peak and you know how long it takes to generate your pages So you can use this this handy-dandy little equation and you can say okay my pages Serve divided by my minutes Multiply by my execution time divided by 60 will give me the concurrent processes I need to serve this request so my example down here I've got 2,000 page views server for five minutes if it takes a third of a second to serve them all that I only need 2.2 to concurrent processes to to serve these requests So I'm gonna be great. I'm gonna be great because we just figured out that my my website can We know that my web server is set to 10 so I can run 10 concurrent processes now This this will bite you in the ass if you use exactly like this because you know not all of your users are just waiting You know and making the requests, you know in nice order You might have like 40 people make a request all at once So you would logically you'd want to you'd want to try and work that out You want to maybe try and say okay chances are that my spikes are really sharp on my web server Which means I'm getting a lot of people making simultaneous requests Sure, I've averaged them out over a particular period of time But I know that you know within that five minutes I have I have high points in there So you either a just want to multiply that number by something like four to say, okay You know that's gonna give me some headroom or maybe you want to get smaller sample You want to figure out like you may be down to like half a minute How many requests you're getting in your very top half minute of your peak and base your numbers off of that But you want to you know you want to be smart about that So after setting all the stuff on my website aside to hammer it and unfortunately this isn't well in focus freeze You can't see it in great detail, but I use a patchy benchmark for these tests Patchy benchmark is probably not something you want to run a full-scale web test against but it gives really cool stats And I like seeds doesn't seem to give sort of the level of detail that I like or there's a setting that that's Unaware of but the Mac I made a thousand requests with a patchy benchmark against this server And I requested a concurrency of 10, which means I'm being gentle on my server I'm saying I know it can handle 10 requests at times will only serve only asked for 10 requests at a time So it took 21.4 seconds to serve those thousand requests And I was actually able to serve 233 requests a second, which is pretty freaking awesome actually I think and Down here in the the left-hand side you'll see that my my lowest request was served in six milliseconds and 99% of the press were served in under 89 milliseconds, which is pretty good So the next question is well, what can we do now? So I then said I want to make a 5,000 requests and we request them a hundred at a time And so the interesting thing is that my website survived this and actually survived it fairly well It only took 28.9 milliseconds or 5,000 requests whereas before I did I served a thousand twenty one So you look at that you think that's pretty good And the reason why this happens of course is because the operating system when Apache says hey I'm full I can only take ten requests. You know your operating system doesn't just say sorry guys You know you're getting you're getting a 500 error of some sort It'll just queue them up and wait, but the thing you'll notice here is that my mean time for request is significantly worse So I'm at 42 milliseconds to request there and now I'm at 578 milliseconds is my mean time to serve a request which means my users are not happy with me now Their website their pages are loading a lot slower than they were before and that's because most of those users are sitting in queue Waiting you know for Apache to get around to serving the request of patches fine my run queue when I ran these tests and the servers It's had a wrong like I don't know wasn't it was like point H or something like that So it was good, but a lot of the time that might the user were dealing with we're spending just waiting for those requests to come through So then just for kicks. I'm like well, what if I take my server limit and I change it to 20? Like I know I don't have the RAM for but maybe the maybe the disk can handle it And I'll swap the mobile right and what we'll discover is that it takes longer by setting it to 20 So I've actually I've actually made my made my test take longer and I've made the the users Wait longer as well. So this kind of interesting You know, I had if I had my web server I know my web server wasn't really adequate for the task and I but I was being you know I was setting my maximum that properly I've done the math I figured out how much RAM it took and how much RAM I had available I knew that I could handle 10 concurrent processes Apache was not gonna have to start swapping on the disk to serve those 10 concurrent processes because I had enough RAM for it But I was I went over that now the thing starts to get worse And if I actually set this to 40 the same test will actually bring the server down It'll actually lock up. I'll have to reboot it when I would do that So that's that's an important thing to understand and just to give you guys an idea The default setting in Apache typically is 150 or 256 depending on the version you pulled out So and if you think about if you think your website takes a hundred megs of RAM That's a conceivable number to get a page out the door and it's at the 256 You better have a lot of RAM on that machine available to serve your web request Otherwise patch is just gonna say yeah bring them on I can serve these requests and it's gonna say shoot I'm out of RAM and then it falls over so you do not want that you want you need to go in there You need to tweak that setting the default install in Apache is designed for HTML pages It's not designed for for you know a CMS like Drupal and it will it will bring your site down But the good news is like I said that you can you can still handle, you know more traffic than you should be able to handle Because if you if you're telling if you're not make forcing Apache to do to more work than it can handle You know the OS will queue the requests and they'll all get through without bringing your site down This site could have handled, you know 100 concurrent requests for forever And it wouldn't have gone down now some of the users might eventually have got timeouts on their request But the server wouldn't go down which means that you know worst-case scenario You don't have to sit there making a call to a data center getting the reboot of server in the middle of your peak You might just have a couple people that don't get pages obviously still not ideal, but it's better than the alternative So after doing all of this You then need to assume the worst You need to assume that you just got slash dotted and you've got more requests And you've ever seen coming to your website and like I mentioned before that content editor sees that they've made a typo in an article and They go and edit a page and it clears cache and Suddenly Drupal has none of this data in cache memcache has been cleared a PC has been cleared And everything is being built up from scratch Now if we remember when we go all the way back to the slide Scratch was a lot longer scrap, you know when I'm running well I'm able to serve requests in 42 milliseconds when you're building things to scratch It was taking over three seconds So what you really should be doing is you should be going and running all of these tests that we just went Developing all of these numbers all of the stuff with Drupal page caching turned off assumed that someone made a mistake someone was doing something last night and they turned off page caching and You don't have that available to you and that you're taking longer to run your request. So when you go back actually to the What do I want to pop back to here? When you go back and you get your numbers from the develop module or from where you want to get them Make sure that when you do when you get those numbers And maybe you have to you have to spin up a test site and mimic the traffic to do this But you get those numbers, you know with page caching turned off because you need to assume that page caching is not running When when you get hit I mean granted that you don't you don't ever want that to happen But you don't want to be in that position where your servers cannot handle anything like that or you know Or cash gets cleared or something like that or or just it turns out that you know a bunch of your pages You set like a good number you set an hour or something like that but that number happened to coincide with in the middle Of a spike. I mean there's a lot of reasons why that could happen now on the flip side You could simply just go and And turn off all of your cash or turn off all those features about modify it modified court But Dries will find you and you won't like what happens. So apparently I'm actually going really long here I just realized I hadn't looked at my time at all But there's some some other optimizations you can do and one of them is that Drupal is a giant four four handler That's really what it does. No other URLs you hit exist. It's a giant four four handler where it says, okay Here's this pretend you are well, I'm gonna pass that index dot phb is a variable and Drupal will know what to do The problem is that if you get a website and someone made a mistake There's a gif that's not not there anymore, you know, and there's a jpeg that's not there anymore in there in your CSS file That means that you're actually taking three page loads to load a page because page loads up There's missing in there's missing files and Drupal is like one I'm handling those files So it's serving pages to the browser for missing gif and it's serving a page for missing You know missing missing jpeg or something like that and instead of taking you know in my case 11 megs of ram to load a page it now takes 30 megs of ram to load that page because I'm serving these 404s at the same time So there's Drupal 7 didn't quite get it in but if you Google if you look around Drupal.org There's a thread on how to write some code into your settings dot PHP to make to basically detect Extensions you don't want Drupal to serve with the exception of image cache URLs and serve those You know just as just static little header and like a little bit of text saying this is a 404 In addition, there's a module that actually I'd make all fast for or for that You can check out as well that does that sort of thing as a module and it'll also do it for URLs You want to be careful with cookies because setting cookies will clear your varnish cache I won't get in that in great detail and path alias cache is a really big thing this comes with press flow in Drupal 6 So that's how you can get there what happens is if you think about every single you got a front page You got all these nodes slash one node slash two nodes slash three and all that sort of thing But you've enabled URL aliases then what Drupal is going to do is for every single one of those It's going to make a query to the URL aliases table and say hey Do you got an alias for this thing and if it does it's going to use that alias instead? The problem is you could have hundreds of those on a page if you're thinking what a front page of your site It's got a lot of block showing views and whatnot. You are going to be making hundreds of extra queries So the path alias cache what it does is it says okay for this page? These are all the path aliases on this page I'm going to store them all as one big chunk and that way we don't have to make hundreds of queries We just make one query and get those out Like I said session data caching whoops session data caching is something that you go back up that you definitely want to do You want to use the memcache module do your session data caching or you can use a PC and cache router for that sort of thing Examine those views like I said you really want to be looking at those if you if you run develop You see a bunch of views are taking forever to load you want to examine those views run the explain query against them I'm don't have time to talk about edge site includes but there's a module on Drupal or called edge side include ESI You want to look up that module that module can allow you to actually use varnish and In concert with logged in users and serve them some cache data mix in with some non-cache data and save yourself a lot of pain And the last thing you can always consider doing is making it so your front page is always cash regardless of who they are I've done this before with varnish You could actually get away with doing this in Drupal as well Where you could basically just on like hook boot you could learn you could write senior bootstraps Depending on how you're how you want to set this up or you could look and say okay, but even though the user is Authenticated, this is my front page I'm just gonna serve them a cash page anyway because the majority of your your pages probably hit your front page So that's always a good option to consider and then front-end optimizations are some things you might want to look at I don't want to talk about this in great detail, but those are options Mod page speed something that that Google has made mod page speeds Actually, what it does is in the it's an patchy module and what it will do is it will say hey You've got like inline styles I'm gonna put those in the head and you Drupal already does this for us But it'll aggregate all of your JSS and CSS files But it'll do as well as I say oh you've got all these CSS background images Combines all those into one sprite and then modifies your CSS to show just what it needs to so instead of serving like 40 files If your background images that serves one and your browser caches and sauce making all the requests So it's an awesome thing CDN reverse proxies, you know varnish is a big one if you ask anybody about varnish They'll be able to give you a lot of details on that and then domain charging is a pretty cool thing too That services like Yata will offer and a couple other ones as well where a browser by default It's probably getting a little bit higher in newer versions will only make two requests at a time So if you saw my one example there, I had 11 Things that need to be loaded load my page my browser can ask for those two at a time What the main sharding what a lot of services will do is they'll give you like, you know, you know Subdomain one dot your domain comm subdomain to your domain comm subdomain three and they'll actually the mod page Speed module will do this in concert with some CDNs as well on the fly And it'll rewrite your html to make as an assets load from different subdomains and the browser request them all at once Rather than doing them all on serial fashion and you'll get your page loading a lot faster. So that's that's a pretty cool thing as well so You know, that's just sort of the quick summary, you know understand what's going on to the hood ensure everything's caching Check your headers tune my SQL. That's just an obvious thing and use key value stores. It's not rocket science It's not, you know, a terribly difficult thing. That's that's what it would take to to make your sites load that fast So does anybody have any questions? Yes Yes Okay, so the question was that my school allows you to use different storage engines for different tables This is true. You don't have to use in ODB for everything or my is and you can use the in-memory storage table And that is that is definitely an option you could say for these one these particular tables that are ephemeral I don't care if they get wiped out with my skill restarts. You can store them in memory The one reason why you may not want to do that is because maybe maybe your my SQL server You're hitting it so hard that you're worried about opening up more TCP IP connections and using more of its internal caching memory for dealing with that stuff So if you use memcache, you're just sort of spreading out the load between different daemons But the result would be the same provider my SQL server had enough memory to handle that had enough You know had the TCP TCP IP socket so it could do that just fine Anything else I Can't see very well. Oh, yes. I'm gonna ask if I didn't mention was it like II? Okay, I I do I think a lot of other web servers are great Like I mentioned engine X is when a lot people talked about too But the one that the majority of us are gonna find ourselves running for a variety of reasons is a patchy If you can get away with running one of the faster lighter web servers You should definitely do it because they're faster and they're lighter the downside those So someone might may come to you at some point and say hey We need to XYZ and you're like shoot now We need to rearchitect our entire system because we we chose a server that can't do this one thing But if you think you if you know your scope is fixed, it's a great option Anyone else? Yes Okay, so the performance module has been removed from developments looking for help So I'm not sure if you're asking me to help but I could think about that But if anybody's interested that's that's a very important module. It's pretty key anyone else. Yes So the question was do I recommend my ism or in no DB and the big difference between those? Sorry Or the other way around Then actually, you know, I work at Acquia in the and I sit behind the hosting in the ops guys And there's a lot of discussions about this and I've always actually been a preferred my ism The problem is that my ism on inserts and deletes does full table locks whereas in no DB does row locks There are certain tables in Drupal that perform better on my ism than in no DB For example your watchdog table and if you use the statistics module your access table will actually perform better under my ism Then they will under in no DB So if you want to really play around and tweak in tune you could pick certain tables and run one table on one engine and one table On another tables that have a lot of inserts and deletes going at the same time though in no DB is your best choice all the time for those Yes So the point made was that there's a member there's probably a there's a memory leak problem in the in memory my sequel engine You don't know if they solved it. Oh Okay, or in lady. Sorry Okay Yeah, I haven't really invested you played around with those a lot I do pretty much everything in Apache so but yeah, you definitely that's the other thing too is that with Apache you know That it's gonna be fairly solid and if there are problems there's gonna be a thousand forum posts explaining them So that's one of the reasons why it's better too Thank you. Thank you. Oh and Go and take the survey if you like my presentation. You'd like to see more. Give me good marks. Thanks. Have a good Have a good session for good Drupal con