 first of all, who am I? Because I'm not like super well-known in the community. I have been doing Drupal for about nine years. I've been working on commerce stuff since way back in the UberCard days. So since UberCard Alpha, right after it was announced at DrupalCon Boston, so I do have a lot of experience working with it. I work for Acro Media. We are based in Canada, but we are distributed all over the world. We have about 60 staff, about 40 of which are developers, and we work exclusively on Drupal commerce. So not only do we just do Drupal, but we actually only do Drupal commerce. So we're pretty specific to this niche. So hopefully I can help out with a lot of details around commerce. Okay, into the topic. Why is commerce slow? Because you're probably here because commerce is slow, not because it's so awesome, and we're just all going to talk about how fast it is. Although if you are, that would be great. The biggest problem is Drupal relies a lot on anonymous caching and anonymous users to be fast. That's the primary, especially with Drupal 7, that is the primary way to get speed, is to have page caching, to even use varnish in front of things, stuff like that. That is rarely the case for Drupal commerce that that can be useful. Because most of the time you're actually doing stuff, you're loading dynamic pages, you're doing stuff with your users that means you can't cache that. Also the way Drupal 7 works by default is that once you have a session, you are not cached anymore. Like you might use form caches, things like that, but the page cache is no longer being utilized. So that doesn't mean you actually have to be a logged in user to basically count as authenticated. Once you have a session, and so in e-commerce what that means is once you add anything to your cart, so once you add to your cart suddenly everything is not page cached anymore and so you're going to go from maybe you have 100 millisecond page loads to you have, or like response times to 500 millisecond response times just by someone adds a single thing to their cart and that has nothing to do with the cart itself being slow, that just has to do that we drop page caching completely. So we're going to talk about various ways to get around that, various things to do without having caching and stuff, but it's all going to hopefully be pretty commerce specific, although it can be useful for other sites that do commerce-like things where they're very dynamic, they don't have much use of traditional Drupal caching. This talk is actually also going to be mostly on commerce 1.x for Drupal 7, although we will touch a little bit on commerce 2.x for Drupal 8 at the end, hopefully if I go fast enough. First thing, to just get this out of the way is use PHP 7 if you do Drupal commerce. It does work perfectly fine with commerce. There is one very small patch that you have to apply. It is in the dev branch of commerce already. It is not in a live release and if you see Ryan Sarama just yell at him about that. That is the only hold up as we need a release tagged to get that and I'm now conducting like a small gorilla campaign to get him to do that. So I harass him at every opportunity. But as you can see from the chart there which hopefully you guys can kind of read, the first two bars there are just for standard Drupal and the next two are for basically really standard product page from Drupal commerce. That just comes from a commerce kick start example and you'll gain about two and a half times performance. So out of all the stuff we're going to go over here, that's probably the best performance increase you're going to get and it's also the easiest. We run most of our commerce sites now on PHP 7 and there's very little problem with that. Like I said, there's one small commerce core patch and otherwise most contribute is actually already patched and it works perfectly fine. And yeah, the performance is both in speed and in memory you'll get about the same benefit. So you get about two and a half times performance and you will save probably about half your memory at the same time. So good for performance and good for scalability as well. Oh, and I have a bunch of graphs and statistics and stuff here. If anyone wants you can just, you know, grab me after the talk or something or message me on Twitter and I can provide like all the data I used to get all that stuff because I ran a whole bunch of testing and benchmarks and stuff like this and I have more than just what I'll be showing in these slides. Next thing we're going to go through a few different modules and sort of different performance options and how they relate to Drupal commerce because you can get pretty mixed results depending on what you're using. The first thing is entity cache. Now specifically there is a commerce entity cache module that handles putting products orders, commerce stuff basically into entity cache as well. This is to be honest going to be of limited use and you'll get some advantage where you aren't able to use page caching and you are able to load entities but that's only if you have, it will help you on like a product page where you're maybe only loading a single product. It will actually be a fairly significant detriment to you if you are on a large page like a big catalog page or something that's going to load 30 to 40 products. It'll probably give you a 30, 40% performance decrease. So overall that one you can use in specific cases if it works for you. I would test it quite extensively and I would overall probably not recommend it just because it's going to probably give you more performance decreases and it is for increases. It doesn't work by default. It has support for orders by default but they tend to sort of break data consistency with orders because they will cache them sort of too long and they don't handle any sort of order locking setup. So you can get overwrite issues and stuff. I'm just going to keep an eye on the time here. AuthCache. So this is actually going to help you a lot more although it is a little tricky to set up. So basically for anyone who doesn't know what AuthCache does, it gives you caching when you're an authenticated user and so that applies to if you have a session, if you're actually logged in, any of that stuff that you don't normally get caching for. So this can actually be really, really great for Drupal Commerce because like the problem I talked about before where if you have pages that the user's added something to the cart or you show a simple view cart button up at the top that says you have two items in your cart. Well, that's technically dynamic and so that's going to screw up your whole page as well. And so if you set up AuthCache, you can do page caching either just through the database like normal or paired up with varnish for those pages. And as you'll see in the graph, you get really significant page speed decreases. Like I said, you can go from about 400 down to just over 100 milliseconds. This is response time to the server, so this is basically the PHP MySQL or whatever red is, whatever you have paired up there that is running. This is not necessarily the page load that's happening. So it works with Commerce Core out of the box. It actually has specific commerce support built into it to handle carts and stuff like that. It is adding like a whole different caching type layer. You have to turn off regular anonymous cache. You have to use AuthCache. It works pretty well. Any customized stuff you have may give you difficulties. If you've put things in templates that you maybe shouldn't have put in templates, those will cache wrong. If you set up blocks, maybe the way you shouldn't have, those might not work right. Also, you're going to have to possibly tweak your pages to make sure that they do work with AuthCache because if your page is flagged as unable to be cached, it's still not going to cache even with AuthCache. You don't just turn it on and it's a magic bullet. So it actually has a debugging set up that you can turn on and you can hit any page and see if it's actually hitting the AuthCache or not. So what that is going to, and that's going to usually tell you why it's not hitting. Do you have a dynamic element on the page? Is there something that's causing it to not cache? So you can do things like if you have a couple of blocks, if you have like a cart block is going to be one, for example, you can set that to load through Ajax or through Edge Side Includes. So you basically, it's sort of a precursor to how big pipe works now in D8, but you can load those after the initial page load. So you can cache that initial page load, get the quick initial load, and then get the load after that. You will get a little, you'll get better speed. You will get slightly more load on your server because you are bootstrapping Drupal multiple times there. So I mean, that's a standard project or problem for most Ajax loads. There is also a JS module which will reduce your overhead for Ajax requests for stuff like this. I haven't tested the two together. I've got good results with AuthCache and I've got good results with the JS module. I haven't run them together to see if they run smoothly or not, but just keep that in mind as well if you're trying to tweak for performance. Redis. And this is somewhat applies to Memcache as well. I wasn't able to do full benchmarks for Memcache as well before this. Redis is not going to help you as much as you would hope really. You know, you go, okay, I have all these dynamic things that I'm pulling from cache. I'm pulling form cache and field cache and all these other things that I can't do because I'm not using page cache. So Redis is going to help me there. That doesn't really pan out in the benchmarks. As you see here, you get in some instances like where you can actually use full page caching, you get a small performance decrease. When you are using stuff that can't be fully page cached and has lots of elements like a large catalog page or the cart page, you do get some improvement. But that's going to be really variable. That's going to vary a lot between your setup, what you're loading. If you start to hit cache too heavily, it can sometimes be a little better on Redis. If you're hitting cache fairly lightly, it will actually be worse on Redis. I would really try to benchmark that quite a bit on your setup. And I will talk about benchmarking tools later on. Because it's not everyone kind of gives us advice of if it's in Drupal in general, they say, oh, just install varnish and set up Redis and all your performance problems go away. That's not true in general, and that's definitely not true for commerce. So be very cautious when you test Redis. And what it can often be doing is if you add Redis, you will see a performance improvement. But it's because you're just, you're adding more resources. You've set up a new Redis server, you're adding that, and you're just offloading work off your database. You're not actually going faster overall. It's just that you've split something up between two setups. So oftentimes it can be an initial problem with your MySQL server, you just need more resources there. Or you need, you know, more, you need to configure to use more memory. So it's caching tables properly. MySQL will load up everything in memory as well. So Redis is not, you know, you go, oh, it's key value store, it's in memory. You know, so for some reason, it's supposed to be way, way faster. That's only going to help you a limited amount. So proper tuning of your MySQL server, I would say would be the first thing to do before you immediately just toss Redis on there. Next one. Varnish, like I mentioned, this is basically if you ask anyone about Drupal performance, before you've even finished asking your question, they're just going to say varnish. And they're going to tell you that that's the answer to everything. It's like, oh, we just put a varnish layer and then Drupal super fast. That's mostly pointless for commerce. Because like I said, so many things are dynamic. So you're going to have so many cache misses on your varnish layer that you're really not going to get the speed. Your homepage is maybe going to load great. But after that, it's going to be very limited in the performance you're getting, because you're just, you're going to miss this cache all the time. If you do some of this stuff with auth cache, like I talked about before, you will get a little bit better, you will get better performance because you'll be able to use varnish for some of these things. And I would definitely say you can still use varnish like I'm not saying don't use it. Just it's not going to be the sort of silver bullet that solves all your problems. Okay, order locking. So this is a specific problem that you can get within commerce. So if you don't have any issues with order locking or specific pages or something, you don't necessarily have to worry about fixing this. But how this works, and I'm going to kind of have to go into some of the back story here, is that commerce has this sort of very basic pessimistic order locking setup. And so what that means, the difference between a pessimistic and optimistic order locking is pessimistic order locking, when you load something up, it says, I might edit this. So nobody else touch it, because I might change something. And if you change something as well, then we'll get screwed up. The problem is, is well that prevents you from having any screw ups. It also means no one else can work with that setup. And in the instance of Drupal commerce, because it uses, basically, there's some very simple default sort of entity locking built into Drupal 7. And commerce basically just took that and then used it probably a little more than it should have been used. So you have, anytime you load up an order, it is going to lock, it's going to do basically a MySQL for update select. And so that row is going to be locked from anyone else loading it, any other selects on that, until basically the whole page load finishes, and the database connection is closed. So sometimes that's fine. Most times people are just running one, you know, they're going through looking at their own order, page loads happen pretty quickly. So most of the time spent looking at an order is actually looking at a static screen and nothing's happening in the back end. Where this can cause real problems is if you do, if you have order management screens that show lots of orders, if you have reports that load up orders, those are all for the duration which they are loading, going to lock any orders that they touch. So that means none of your CSRs can edit those orders. Anyone who's a customer, like if you're still doing these for in-card orders or something like that, those orders will not load, they will hang. If you have concurrent Ajax stuff that runs in the background and things like that, one of those can block the other and so you'll get maybe twice the load time that you actually need. It's a bad way to do order locking. It shouldn't have really been done that way. It just wasn't really thought through much. It basically used the standard Drupal way and then it just doesn't scale. And it does not immediately apparent. You have to have these sort of cases like I described or you have to specifically simulate it. So how to fix that because that sucks is there's a patch which I've linked to there or there's a big thread with the number of patches in which will limit the instances in which we order lock because by default commerce will order lock everything. And so lots of stuff you know, if I'm looking at a view of orders and I can't edit on that screen, we don't need to lock any of those orders because I'm never going to change them. So there is a patch there that will make the pessimistic order locking a lot more specific. So it will only happen on like order edit pages, cartload specific things where you're likely going to be changing that order. But the second option is you can also just turn it off, which is actually what we run on a lot of our sites because it only locks during the load. It's a very limited benefit. It's not preventing two people from loading up the same order. And then one person edits it and then the other person edits it. That can still happen. That's the thing you have to sort of manage with revisions and stuff like that to keep track of those edits. So we just usually remove it because then we have no locking issues. And that can be a real problem for us. This can be one of your biggest performance things. You'll notice it in sort of weird strange spikes in response time that you won't really be able to track down. And the way you can find that is if you have something like a New Relic or even slow query log or anything like that from iSql and you look in and you'll see four update queries tagged in as part of the stuff that is taking a really long time. And those are blocking or like locking queries. So those are what is your problem. And why you're getting those is because you're having an order locking problem. So you can always come and bug me if you need more info on that. I wrote a bunch of the patches and the issue there and everything and I'm involved all throughout it. Next thing, database locking. So this is a standard commerce problem although it becomes particularly apparent in Drupal commerce because Drupal commerce is, it uses a lot of fields and so it really sort of strains the whole entity system. Orders will have many fields attached to them. Products can oftentimes get very large. You also have product variations that are attached to products and so you're loading tons of entities. So lots of effort and load is being put on the whole sort of entity caching layer, field caches and stuff like that. And by default there's a basically different isolation methods that my iSql uses and by default it won't use read committed. And it'll use a way that basically to sort of keep for a little bit better insert speed which for us in Drupal doesn't really matter. It will basically lock the rows around whatever it's editing. So it will say hey I'm editing here and I sort of need to lock the IDs around there because I don't know if I'm going to change this. Maybe I'll remove this ID and then like things are going to have to shuffle up or something. So it locks these whole sections and so now you're doing, you know you're loading products, you're doing other things and you're locking basically sort of strips in your database. And if you need to load all these products, you need to load orders stuff like this, you will get stuck in deadlocks and these are ones where it won't actually go slow. It will get stuck and it won't work because it'll say I'm trying to load this but you've locked it, it will time out and the whole page won't load. This one thankfully is easy to fix and pretty easy to diagnose. You will see in your MySQL logs and it will even pop up into your Drupal watchdog. You will just see deadlock errors and you'll see that they'll all be on like the various field tables and they will just spam through your error logs. The thing is you just have to change your transaction isolation to read committed which is pretty simple. You can do it at the database level or you can throw a single line into your settings.php which will fix that and like I said you'll sacrifice ever so slightly much performance that you probably won't even be able to notice it on inserts and you will get, you will totally eliminate your locking problem and that can be, this comes up quite common in Drupal sites. This is like a really standard thing we do. We basically put this in most of our sites by default. This work, this fix here and a bunch of other cool performance stuff comes from the pretty darn quick cache module which I've linked there because it's got a bit of a wordy name and a confusing abbreviation. It has a whole bunch more database tweaks and tunes and stuff you can get. It's not commerce specific. It just does database stuff in general but this is a specific, this is one of the sort of basic ones it does and so I just, if you want any more information for it you can go there. Commerce calculate price. So this, I'm not going to have as many solutions for this one too. It is, it's kind of just a bad way that commerce 1.x was architected. Every time we show a price in commerce we have to calculate what that price is. And I mean every time we show a price. So if we show a whole list of pricing on a catalog page, if we show it on search results, even when we show a single price on a product page, we are always calculating that price and that's heavier than you think because we're calculating everything we're saying, hey you know is there any reason we need to change this because of the user, because of their location, because of what the product is, are there any discounts applied, are there any sales active? Any pricing rule that is going to run is going to be run every time you load that product. So if you have a catalog page has 30 products, you have, you could have really easily 25 different pricing rules. 25 different pricing rules are going to run times 30 and that is going to actually add a pretty significant time to it. So obviously try to cache those pages if you can and if you can't try to at least be cautious of what you have in your pricing rules. We get a lot of sites where they can bloat up a lot so people will have, they'll have four years worth of discounts set up in there, they'll have a ton of tax rules they don't use, they'll have way more, they'll have four or five times as many pricing rules as they need. So just go through your list, you can even look at it directly through the rules UI, just go through it and audit some of those out. You're not going to get a crazy performance increase you know but maybe you save you know 20, 30, 50 milliseconds off your page which can be significant depending on how messy your rule setup is. So otherwise unfortunately there's not a lot to do with that. That is totally fixed and way better in commerce 2.x which I will touch on later. So we didn't just keep doing the same stupid thing over and over again. Regular stuff. So this stuff isn't really commerce specific but it's some standard performance stuff that tends to come up in commerce quite a bit. First one, this is really simple, it seems like nothing. Don't have any variable sets that run on anything that isn't like a one off config page. Every time you run a variable set, you clear the entire variable cache and it has to be redone. And depending on your site, this might be like a 2 meg cache that is getting redone. And so you can be redoing that every page load and that will absolutely destroy your performance. You might have a simple thing where you're just trying to set like, oh, who is the last person that viewed this product or some sort of silly thing like that. It seems harmless but it will just destroy your performance. It will turn your page from working to almost unloadable depending on the size of your variable cache because it's a one thing that you cache all the variables. It's every variable for your entire Drupal site that is basically going to be dumping in there. Which is just like I said awful. It can be megabytes for even not particularly large sites. Next, use all the normal stuff. Page cache, block cache, compressor, JSC, all that stuff that's in Drupal. Make sure you have that turned on. It sounds stupid but lots of people will be missing that and it turns out, oh, we're not caching blocks. And so you're loading menus, you're loading other things. Commerce, you might have huge menus that list hundreds of products in them and stuff. If you're not caching those, that's terrible. So make sure those are turned on and then maybe even check the blocks that you use a lot and make sure they actually are caching. Blocks may be set to not cache. Depending on what modules you have, you can turn that on manually. It may come from modules that you've installed and they will have non caching blocks. And like a simple block, you know, on the side of your page that does something seemingly minor will destroy most of your performance. I touched on it a bit. Audit your rules. I was talking about pricing rules. Audit all the rules that you have on your site. Rules fire all the time in Drupal Commerce. Most of it is based on rules. And they can be doing really heavy stuff. They can be doing big, heavy calculations. They can be doing lots of stuff or they can run all the time. There's lots of stuff that will run on add to cart. That it will run on order update. Things that happen all the time. So check what you have in there and make sure it actually needs to happen. It's not either could just happen less often or it maybe is just old and doesn't need to happen at all. Or maybe you can do it in a different way. So, you know, you might not get a lot of performance from any one rule, but from a bunch again it can add up. The next thing, check for anything that is setting or screwing with cash. You can get really weird problems from small little modules and stuff like that that you can have an otherwise performance site that has one small quirk and one country module that you've downloaded and then it can destroy your performance. I'm just going to go with a quick example that we found when we're doing some performance testing. We found that commerce field group pains, which is basically a really simple group. It makes you take, it takes a field group that you set up for like a commerce order and it turns it into a checkout pane. It's not a very big module. It's very simple. It hasn't really had many updates because it does one thing. It basically works fine and that's it. The problem was is it had a very small thing where when it loaded the field info it passed a flag as false that should have been true and what that meant is that flag said that all the field cache gets cleared. It said I don't want to pull from cache. I want to pull fresh. There was absolutely no reason for this module to do this. It was a simple mistake by the person who was writing it. They wrote the wrong thing in but that resets your entire field cache on every page that loads a field group. So any checkout page ran you would clear all the cache not just for you but for everyone right you're clearing the whole cache for fields. So if you have even one person going through your checkout they are clearing the site for everyone. The more people you have going through the checkout the more times you're clearing the cache. So you're getting all you get almost no benefit from caching. So there's little things like that that you have to watch out for. So if you see in your auditing that you have you know cache loads that are happening they shouldn't and cache that stuff they should not happen very often. If you see those popping up a bunch you probably have something wrong and you're going to have to drill down a little bit unfortunately to find out you know where those are and what problems they're causing and usually this fix is actually really simple but it might take you a while to to arrive at you know where the actual problem was you know commerce field group pains was not the first module I looked at. It was probably the last module I ended up looking at. Next thing tools and testing so stuff that you can use to help you figure out Drupal commerce so and what the performance problems are because it can be really really difficult you can just have a page that it's just slow and why the hell is it slow it it shouldn't be slow you know it's not doing anything complicated it's loading one product you know it does nothing like why does it suck and so some stuff you can use new relic and black fire are both really good if you haven't used them before new relic is is like a pretty good monitoring tool it's mostly just like a regular Drupal stuff xh prof like running in the background but it does it in a really nice UI it gives you lots of things it sort of will pick you know important results things that are particularly going slow grouping together it's very helpful it does have a free version I think it will only store your data for 24 hours or three days or something like that but it can be really helpful that you can just turn it on look see what your couple of top performance things are hit those you know see if you fix them and you don't need weeks worth of data if you're trying to find more edge case stuff you're gonna probably need to pay for that longer amount of data but you can get a ton done with the free report it has most of the features it just doesn't store the data for a long time so it's it's very useful and the free offering is quite robust blackfire is similar although it is more of a sort of test driven type of approach so it's sort of something where you can say hey you know run these pages and stuff and I expect like these performance results and if and it's going to basically generate you a report about that and you know why didn't you hit that what wasn't performing and stuff so the actual data you're going to get from it is fairly similar but one sort of more of an active monitoring and one's like a testing something you more run on you know devs and staging and stuff the next thing is you can just use xh prof directly a lot of those other ones they're actually basically a layer over top of that and they do custom stuff and things like that but xh prof is going to show you what run it's going to show you basically all the functions that run on a full page load for you and then it's going to show you how much time they all take and so that's where you're going to drill down to find out what is causing a problem because you'll probably get something upper level you know hey this you know load product function is going really slowly right but it's probably not load product itself that slow you're probably just going to have to drill down and you're going to find okay this goes in a half a millisecond this goes in a tenth of a millisecond this goes in 30 milliseconds okay why is that and then you can pick those ones that are specific that you think as you kind of have to use your intuition a little and as you do more you'll get better at it but you can usually pick ones that you know they're big and they there's no reason they should be bigger you'll you'll see function names that seem innocuous but the time just doesn't match up and then you can go into those take a look okay next thing is the devil query log that you can do and so it can basically you can turn it on for the develop module and down at the bottom of your page it will just show all the database queries that have to run and how long they took to run this can be just a really easy one to see if you have a second single query that is running bad on a single you know you can just have one little one up there's an index missed somewhere in some in some custom thing you made in some contrived module there's something that's causing a bad database thing it won't help if you have things or won't help too much if you have something that's just running way too much it will kind of point that out but it won't necessarily give you indexes where the problems but slow stuff and things like that it will flag that really easy you also get it from your slow query log but this just gives you a breakdown of everything that was loading on the site you might have a thing where like all these queries are running and why do they even run they shouldn't run on this section stuff so I won't touch on that too much but you see we haven't been using that that's very good the slow query log from isco which you can turn on is very similar although it's only going to get slow queries it's not going to get queries that run way too often or queries that shouldn't run and things like that you have to go in in more detail there the next thing is benchmarking tools Jmeter is amazing it has tons of features it's really good its UX is horrendously bad you won't be like it will take a while to actually get it set up and to get it working and especially if you have to test with commerce because you can't just do a page load that's the easy thing to test that's not where most of your performance is going to be you have to add things to cart you have to go through the checkout you have to go through the cart you have to do all these product flow steps to actually simulate commerce if you're if your first page loads well that doesn't matter that has nothing to do with 99% of your site so test with that specifically test with sessions as well so make sure you set a session in both Jmeter and Apache bench you can set a session Apache bench it's a little lame talking too long on that slide so Apache bench you can actually log in you can create a session you can add things it's going to track your session it's going to go through Apache bench is a little dumber what you're going to have to do is you're going to have to go in your browser you're going to have to do that stuff yourself set up a cart or something and then you can just copy the session cookie out of it and you can pass it through to Apache bench but Apache benches just really helpful for running really quick small tests that you can just run from the command line where it's Jmeter is this big Java monstrosity and if you're not testing with the session set you're sort of wasting your time so and you know you can't test perfectly through your checkout flow you know oftentimes because you have real payment gateways and stuff there but test as far as you can maybe turn on the example payment gateway on your dev environments and stuff like that and try to go through all the way to the thank you page we have problems where people will test like the easy parts and they won't test that last part and then you'll have you know 20 second page loads 15 second page loads on your checkout pages and that will cause people to drop and not use your checkout they will get part way through it will be difficult it will lag it will confuse them they will just give up the threshold people have for buying something and not buying something is super low people will buy on a whim and anything that gets in the way will really stop them from buying it so you will actually get real significant cart drop off you can always check your analytics you can look if you have a particular page that's problem a problematic and then that can sort of focus your testing efforts to be like okay this page I think the UX is okay but people just bomb on that page what's my performance like on that page okay commerce 2.x so first of all a little bit background commerce 2.x commerce 2.x is the rewrite for Drupal 8 of commerce it is not out yet I think the last beta will release tomorrow maybe today which will have sort of most of the functionality and then RC1 will be right at the end of May so probably right on May 31st so for just a little bit of backstory that it is totally rewritten to be like Drupal 8 so to use you know symphony components and to be all object oriented to work with Composer to have all that set up I won't talk too much but just to give you a bit of a background that it is like a full architectural rewrite which means we can use cool stuff performance stuff that comes with Drupal 8 the first of which is we can use big pipe which Dries talked about a little bit in his keynote and I know has sort of gotten some decent press around the community lately that basically lets you do kind of what I described with AuthCache where you can edge load stuff but it's totally built in it's way better and it uses you know cache contexts and all the sort of cache info that we now have built into Drupal core where we can say hey it's not just the page or not the page it's all these parts of the page that I can cache and so you can load 90% of the page and then the dynamic bits pop in later so we load you can do like a really cool example so you want to have a catalog page but you want to show the user some customized products that are just important for them so they're basically say hey you know based on your previous purchase history or whatever use these products or you know view these products and they're probably recommended ones that you'll want but that's slower that's dynamic for each user so that's the thing that we can't cache but so what you can do is you can put maybe like maybe you put you know a top eight products and those are the same for everyone so you can cache those you load them up right away and then you side load in the dynamic products below that so the user still has something to look at they're not waiting for a page load but they and so they get content but then they also get their customized content and so your perceived page load even if your total page load is so low your perceived page load can be much much faster I'm a big I'm a big pipe fanboy I'm a big big pipe fanboy I won't say that again I've spoken out before we've done videos on it and stuff like that it's really cool and it's really good for commerce because it really addresses that whole problem of dynamic pages and what to do with it I actually should have mentioned on here as well although I kind of think of them as the same thing even though they're not really Drupal also has a lot of dynamic page caching built into it for Drupal 8 to handle caching parts of pages and stuff that is dynamic but can still be cached so that lets you you know push it to varnish and still do things like that and do all that stuff that I talked about being such a big problem in seven that isn't a problem in eight and a lot of that is not going to be your problem to config anymore because it's going to come with commerce it's going to come with stuff built into Drupal it's going to be built into contrib modules when you're setting stuff up you have to set all that cache info there'll probably be little tweaks and things like that where everyone gets this ironed out because it's a little it's still pretty new but it's going to work so much nicer for dynamic content out of the box kind of a mix of the points up here but yes and that will let you push all that to varnish as well the next thing we will have optimistic order locking which is just generally a happier term but also means that we won't have any of those order locking problems we talked about before so it will have an optimistic locking setup which says we assume that we will never change the data and we can always load it um so we always load the data all the time and then should we have somehow screwed up and we did edit it and then now we're going to work on it again we just say hey I'm sorry you know we throw an exception we say this has been changed you know you can edit that more you need to reload and try again and so that can be handled sort of on those individual cases and we don't sacrifice performance for that because we assume and we just load things up fast and then we deal with them afterwards in the editing and the smaller one out cases versus the the big loads in advance okay next commerce like I talked about calculating prices it uses something it uses price adjustments now and this actually has a full caching layer which I think is done or almost done at least and so all these price calculations that happen they don't have to happen all the time now they only happen when we're actually doing something to the price so when we load up products and we just want to display them we're not recalculating any of the pricing anymore we are doing that only when we should and so that saves us a lot of speed and price adjustments are also just awesome and they're way easier to work with and they're great for taxes and discounts and other things but specifically for performance they have a real benefit there okay I will try to be pretty quick here so we still have time for questions conditions instead of rules Drupal commerce for 2.x doesn't actually use rules anymore it just uses the conditions setup that's now basically built into Drupal Core and they are much more fine-grained so we don't have these big overarching rules that have to fire all the time we have specific conditions that are already tied to events so discounts know exactly when to fire and when they need to be calculated taxes know exactly when they need to fire and be calculated conditional payment options only go exactly when they have to go so it's both a nicer setup to use from a user experience point and it is a little lighter than the rules setup which was well very robust a bit heavy quick things to go through HDB2 has like a nice module to support pushing CSS, JSS, or JS there's only one S to the browser a lot faster because oftentimes we have heavy stuff will do that if we do builders and flows and stuff like that so that's very good you can get a decent performance increase there works nicely with Drupal 8 there's also a refresh list module which does this really cool like on page loading where you don't load a whole new page and everything look at the demo it's very slick it works straight it will hopefully be really cool for commerce and sorry I'm going to talk really fast so we can get this in here web profiler which comes with the develop module in Drupal 8 it will give you this awesome toolbar down which I probably should have included a screenshot of in retrospect but if you go to the develop module you can see it it will give you this really cool toolbar down at the bottom of any of your pages when you have it turned on and it will show you tons of performance issue or info it will show you you know whether the caching was hit or not what caching was hit what database calls were made you know what your time to first bite was what your page load time it's just all this caching info at the bottom it works really cool out of the box it's been it comes originally from symphony and then it's been edited to work with Drupal quite a bit it is very good and it will help you performance debugging the clock next thing really quick to sort of tack this on here we from Acromedia just started doing a free basically SLA report for commerce if you use it so we are going to we'll basically send out a report which you can see on our website and I've linked just a bit of a screenshot at the top here of which says like here's all the security updates and here's all the various updates that have happened you know in the Drupal ecosystem here's what's you know changed and you should update you know here's important security things here's not that important security things here's what you know test coverage looks like it's for various things so you can try to ascertain the robustness of various modules and performance tips and some other stuff like that so there wasn't a lot of support for commerce in the community so we've been trying to do that you can sign up for that if you want to sign up you can always come by our booth we'll scan you sign you up in like two seconds so it goes out monthly it's just a simple email we'll try not to spam you at all and then we will do the 2.0 version of that once 2.0 launches in about a month so and we have a number of modules we support now and we will continue adding more common modules there okay there we go the last little thank you things and then we will get on two questions just a few people to thanks there Boyan, Torbos Pizza who's Eric, Josh Miller who works for us and Damian who just helped me with various parts of you know fixing performance things in commerce and learning about stuff that I talked about in this talk secondly I have another session with the aforementioned Josh Miller on Thursday we'll be talking all about feelings and lovey-dovey things and basically if you're like an inhuman emotionalist monster like I am you will you know be nice and talk to people and work with teams and and do fun happy stuff we are sprinting for commerce on Friday so we will be I will be there at least for the morning I have to fly out in the afternoon but we'll be trying to be doing sprinting all on Friday we'll set up a commerce table or tables so come around and find us we're Canadian so we got suckered into doing all the Canadian tax work which apparently we have to finish on Friday so we will try to do that if you want to come talk to us talk about Drupal Commerce there's a whole bunch of us around we have these sweet Drupal Commerce T-shirts you can find our booth it's pretty big it says Drupal Commerce and huge letters on it and you probably can't miss it and the last thing if you have any commerce commit creds and you want a sweet exclusive very exclusive commerce committer T-shirt come up and show us that you have at least one commerce related commit cred on your d.o profile and we will give you an exclusive shirt I think it was that there we go last slide okay we're done question time or applause maybe I don't know yeah we'll see we'll maybe try to see if we can just shut out and if not we'll use the mic here but I'll repeat the questions here so okay so do you believe the Drupal Invert statement not so you can play around and view the things that are exclusively to work on yes oh sorry the question was is Drupal Commerce 2.0 stable enough to play around with and to start using yes especially if you don't plan to launch your site immediately then you're fine we have a number of launch site there are probably half a dozen or more sites that have been launched already with it so it's definitely good for that just check a little bit what you need from the contrib ecosystem and stuff like that but we're actually pretty robust we support over 20 payment gateways already now we have shipping we have discounts you know we have all the sort of major stuff in it so it is pretty robust already but if you want to launch in two weeks you know that's maybe a little too fast so yeah oh yeah like it's it's like I said we're on last beta like in a day or two so you can definitely set up a full site you can use it like we've launched production there's like 10 production sites running on it right now so it's certainly robust enough yep how does this compete with magento we actually do pretty well performance-wise that's mostly because magento is crap at performance which at least this is Drupal cons can you repeat that again I can't hear you oh sorry I said magento is crap at performance now that's awkward that I had to repeat that but in general or performance related okay well that could be like an entire talk on itself but as a really quick summary my like magento versus Drupal commerce sales pitch we're really flexible magento isn't very open source anymore they have this like really neglected community edition and then they have their sort of really expensive version now and they don't really help the community stuff anymore they don't do that open source stuff you kind of got to do what they want to do and we try to be fully flexible we are open source you can do whatever you want and so that's our biggest selling feature I could go on for like hours on that but that's a real brief cliff note version yep do these now work on D7 as far as all the stuff I talked to is all D7 related yeah it's all about commerce on D7 yeah and then I talked a bit about the stuff for performance for Drupal 8 I haven't run too many benchmarks for Drupal 8 performance yet that probably won't happen about until we get to a 2.0 release we've tried to keep a lot of the architecture in mind but we haven't actually been running benchmarks and doing the last tweaks and stuff like that so those are sort of theoretical examples we can do instead I just wanted to say there is also a commerce session at 2.15 if anybody else is interested that Ryan and Boyan are doing oh right yes by the commerce guys so Ryan Sarama Boyan Zavanovich who are like the original creators of Drupal commerce and they will have a session this afternoon as well so it's a shorter session it's only one of the half an hour ones they're going to try to go over some of the builds they've done in 2.0 and stuff so that will be more specifically about 2.0 if you want to learn about that there's one way in the back there yes there are migration paths for oh yes sorry are there migration paths for uberkart to Drupal commerce specifically Drupal commerce 2.x yes there are migration paths for both uberkart on Drupal 6 and uberkart on Drupal 7 they are pretty good some people have already used them they could still use a little fine tuning um we actually just recently as of last week hired a commerce or a migrate core maintainer who's going to be working full time on for the next couple of months finishing those up so they're pretty good now and they should be great in a couple of months yes could you guys have a scenario where you have to not as far as that oh repeat the question yes I'm sorry I'm going to screw that up every time multi-store setup like an Etsy style thing and performance regarding that smaller ones with two or three stores not something with you know thousands of stores or something like an Etsy style would have 2.x has a really nice stores set up to handle that commerce is a little bit it's only so so at doing that you are going to have a performance problems probably when you do that because you're still going to be it treats all your products together and stuff like that unless you do like a completely separate multi-site setup so it's not going to do amazing performance for that to be honest sorry can you repeat so 1.x supports some really simple multi-store stuff like you can do like a multi-domain setup or something 2.x has full-store support so it has the complete concept of setting up multiple stores that have their own products their own customers their own everything so yeah fully in 2.x pretty minimal in 1.x any other questions good good okay dope thank you very much yes which i think i have in my pocket so we should we should release candidate in about a month so end of may we'll release candidate and then release soon after that we won't do too we won't be stuck in like like months of ours or anything that's gonna be basically the final version so it'll just be any bug fixes from now before we do our official couple of months couple months after that this compares to the next start like functionality or yeah