Connecting, informing and supporting the WooCommerce Builder Community

Load Testing and WooCommerce with Lauri, Robert and Zach

Load Testing and WooCommerce with Lauri, Robert and Zach
/

Thanks to our sponsor

PayPal

One of the approaches I like to take with Woo Perspectives is letting guests who appear together on the same show run with the episode’s topic. True, I drop in a few questions here and there, but it can get even more interesting when they have a conversation amongst themselves. And even asking each other questions.

When Building Woo Shops, Load Test

I asked Lauri Kasti, Robert Jacobi and Zach Stepek, all veterans in the web space, to dive into the conversation around load test. I won’t try to extract talking points this time because the discussion covered a lot of ground and was filled with diverse perspectives and insights. Also, it got really geeky.

So no matter what level you are at with building Woo stores for clients, if you need to wrap your brain around load testing your clients’ sites, sit back and enjoy the ride.

Connect with Lauri, Robert and Zach


PayPal
Download the PayPal extension on the WooCommerce marketplace to offer buy now, pay later options.

The Conversation

Bob: Hey everyone, BobWP here. "Do the Woo" special episode, the Woo perspective. We were practicing our late night DJ voices, me and Zach. So I'm just going into that mode for the moment because this is such a laid back conversation we have here, and the topic itself lends to that. Anyway, once again, welcome. Episode 99. Would like to thank my community sponsor, PayPal, before I dive into this great conversation. Buy now, pay later option for your clients. They're already using PayPal. It seems to be catching on. I even noticed more are getting into the pay later and breaking it up into payments. So definitely check that out for your clients or if you sell plugins or whatever. You may check it out yourself.

This is like one of those topics that I'm just looking forward to these three just kind of geeking out on because I actually probably will learn something from it myself because I'm not the most knowledgeable in load testing with WooCommerce. But before we do that, you gotta meet these three faces because if I'm just gonna continue to talk, this show's going to go nowhere. Robert, why don't you start with telling us a little bit about yourself?

Robert: Thanks, Bob, and really appreciate being able to be on an "Woo Perspectives." Woo hoo! I don't have the radio voice. I don't think that'll ever occur. Robert Jacobi. I run robertjacobi.com. It's an industry analysis and media site. We publish morning coffee most mornings, and I've been in the open source, agency, SaaS, and hosting arenas for 20 years. So I've touched a lot of these parts. Maybe it's a lot of broad knowledge, not super deep, but that's why I'm glad that Zach and Lauri are here.

Bob: All right, cool. Lauri, how about yourself?

Lauri: So yeah, I'm Lauri Kasti. I'm founder and CEO of supervisor.com. We are building the easiest and most realistic way to load test your website. And I guess that's why I'm invited here. Excited to be here.

Bob: All right. And, Zach, how about yourself? You're a little known in the Woo space.

Zach: A little known. So I founded an agency a few years ago. No longer there. And right now I basically am consulting with a number of companies, one of them being 10up. We're doing a lot of consulting and contracting, working on some opportunities and exploring the eCommerce space together. So that's been a lot of fun.

Bob: Cool, well, I think we are ready to, yeah, to dive into this. I mean, this is one of those topics that, I swear, as long as I've been in the Woo space, it's been load testing. And I'll be honest with you, I understand the word load, I understand the word testing, but there's a lot more behind just those two words. Why don't I let Lauri start out and just talk a little bit about what load testing is. and then I'd like the other two, Robert and Zach, to chime in on this and carry it out. And then we're just gonna dive into it. I'm gonna let you three kind of carry the weight on this and give some builders out there, especially these new builders or builders that aren't familiar with this, the challenges around load testing. So how about it, Lauri? Lauri I should say.

Lauri: Yeah, so I think, yeah, so I think load testing, it sounds like really geeky and something like it's super difficult and difficult to understand, but basically it's only about the thing that how many concurrent simultaneous users you can have on your website at the same time. And that's something that nobody actually really knows really well. So we do know that how fast you are website is right now. You can just go to your website, right? But if you don't know what happens if 100 users or 1,000 users comes there at the same time, and that's the problem. And with load testing you can figure that out, and that's the basic idea there.

Bob: Anyone wanna carry that a little bit further even?

Robert: Oh gosh, well Lauri said users. So when you use load testing tools, users is such a giant word that should be in the world's biggest quotation marks because it seems like every different load testing service... And there's a number of 'em. I mean, Supervisor's absolutely fantastic. I use that on my side all the time.

But you have GTmetrix. You have Kernel I/O. You have k6, which used to be loadimpact. And there's, I don't want to say bait and switch 'cause I don't think that's really accurate, but for excitement's sake, let's call it a little bait and switch. They'll say users, and those mean completely different things. And I'm sure Zach or Lauri can explain better the differences in the users than I can, but sometimes it seems like a user just happens to be a little bot somewhere running versus what an actual user might really do on a site. Yeah.

Zach: That's definitely been my experience with most load testing tools, is that it takes a significant amount of effort to make it do anything other than just hammer the site with fake users, right? So these bot-based users that don't really do anything except maybe go to a couple of pages.

And since we're talking about WooCommerce and in an eCommerce context, load testing is more complicated because you have to do things that a user of an eCommerce site would do. You have to add a product to the cart. You have to go to the checkout page. You have to go through all of those processes because in WooCommerce, especially the checkout stage is really database intensive and heavy. There's over a hundred records being inserted into the database when you hit checkout. So we need to make sure that the site can handle load but that it can handle load at all stages of the customer interaction with the site, up to and including checking out.

Robert: How does a bot fail in that regard versus another solution?

Zach: Well, it's all based on how well you can train the bot, right? So if you can train the bot to pick a random product and go in and add that to the cart and go back to the homepage and add another product to the cart and then go through to the checkout, or the cart page then the checkout, and actually check out, then you're testing everything that load could possibly cause on site. If you're not doing all of those things, then you're missing a step somewhere and you're going to be very surprised when one of those things becomes the thing that takes your site down.

Robert: So that's just like the scripting of it or learning how to script. But I kind of wanna jump back to the user perspective too because I think there are, and I think, you know, correct me or expand upon it, Lauri, but Supervisor handles users differently than say someone like Kernel I/O or loadimpact.

Zach: Yeah, so what we do, we actually have an army of software robots, and they actually use real web browsers. And then they come to the site and they'll click it, click through all the links and add a product to a shopping cart and do all the same things as a normal user would do on your site so that way the test is complete and everything will be tested. The other tools allow you to build maybe something similar, but typically it's really tedious. It takes a lot of many days to build those scripts, and it's still not complete. They don't usually load all the pictures, all the CSS files.

It can be tricky to fill up all the order forms and stuff like that so it's mainly just like touching the base. But we are doing the real deal, so we are sending actually as many users as you like, the site, and they'll behave just like normal people. So that's our approach. And it's completely automated, so we, actually, we can recognize that it's a WooCommerce site, and it can automatically click products to shopping cart without anybody scripting anything.

Robert: So the big difference then is that you're spinning up an instance of a complete browser where someone else may just be using something like Wget or whatever in a different environment? Is that kind of what I'm hearing or is that-

Lauri: Yeah, so basically the others choose to adjust a bunch of requests in sequence, and the problem with that, that it's actually impossible to time them correctly with how they would be actually done in browsers. They can, so if they... The way those work is that you sort of record your session, but it's actually inaccurate because when you have a lot of load, the timings are not correct anymore, so then you don't know what is actually happening. So that's the problem with these request-based tools. But now we are jumping to the really, really nerdy part, like , so flow testing. So I guess, you know, I think the basic message is that whatever you do, you should do load testing with whatever tool, and then there are different approaches and so on.

Robert: Well, so I've kind of looked at it in sort of three different ways. Like, I love to use GTmetrix just for a simple speed test, like where is a static quick view of the homepage? Where am I at? How am I hitting? Google 99's new Core Vitals 4,000 version of software and making sure I'm getting those nice marks. But so I'll use that just as a sort of quick speed test. I think everyone should just do that 'cause that's just a one-off. I mean, if your site is slow with something like GTmetrix, it's gonna be even worse under heavy load. Yay, nay? I'm gonna go with yay. And then sort of that next step is like a load test. And even with like a blog-based site... We're not even in Woo-land yet, you know? If you hammer the heck out of someone's homepage, you should get an idea of where it starts cracking, at what level. You can almost hear it, you know?

Okay, a thousand concurrent users, and all of a sudden it's screaming over the internet. And then I think we really get to the hardcore stuff for like WooCommerce world, which is sort of that complete performance testing, where you're trying to do all of that at once, right? 'Cause you can't put all the article, articles, products and carts and all that into a CDN, so you don't have that luxury of Cloudflare supporting a lot of that. Or can you sneak some of that in? Zach, you're the developer.

Zach: Well, yeah, you can, you know, you can sneak some of those things in. It's all about how you run your test. And you can do a lot with something as simple as JMeter, right? But it takes a lot of effort to get there, and that's where I've been really impressed with some of the newer tools Supervisor included that are trying to use AI to eliminate those decisions and all of that programming to get you to the point where you're ready to run the test. Now you can do just about anything with code. You just have to have the time and the skill to do it, right? So JMeter can do anything you want it to do; you just probably don't wanna spend the time writing all the Java to make it happen.

Bob: Yeah, one of the things I'm curious about, and I'm coming from the complete naive Bob here listening to this, and you're talking about the tools, and there's ways developer can do it, but it's very time consuming. How does this all play into, okay, let's say you have a site. You have several, maybe a hundred products on there, maybe thousands, whatever. And it comes time for Easter and you kinda have a certain crowd or a certain influx of people coming to your site on that. And then comes around Christmas, and now you have a different influx. It might be a lot more, whatever. It seems like, I don't know.

I mean, again, I'm asking this from a naive point of view. Is the testing going to be different each time for those specific, you know, because maybe certain people coming in, or is it pretty much just across the board? It's just that process of going through hitting on a product, going through each step. And I think maybe, I don't know, Zach and Lauri can maybe touch on that 'cause especially from the automated side of things. But is it like you can kind of set it and say, "Okay, here comes a big influx"? It doesn't matter what products are going for. It doesn't matter if it's 10 times or 20 times. Well, how do you prep for that? How does somebody prep for that?

Zach: So I'd say from my experience, the most important things to prep for load testing are making sure your site performs to begin with. So that's probably the biggest step: make sure that with caching turned off, it still works, and it works well. And then turn caching on is just that layer of additional support because if the site performs well with caching but performs like a dog without it, you have a bad site. So taking a look at that and making sure you've set the stage appropriately for this load testing before it happens. And then I always recommend trying to double or triple the number of visitors you think you're going to get. I've worked with a number of companies that have ended up on "Shark Tank," and every time that they have a rerun, they have an influx of traffic. And "Shark Tank" is syndicated pretty much everywhere, so there's a lot of reruns and a lot of traffic spikes.

So you have to make sure that these companies are ready to handle that. And you have to continue to load test on a regular basis to ensure that they're ready each time that those things happen, and that when significant changes have happened to the site, that you're load testing again because you never know if that last plugin you added to support a new feature that you wanted is going to be the one that introduces code that slows your site down to a point where your server just buckles under the pressure of the traffic you have during a traffic surge.

Robert: Zach, I think you made the greatest point because I just came across this a couple of weeks ago. Every time you install a plugin or do an update, I mean, it'd be nice to just say, "Okay, check your site once a month." But I was just playing around with different speed tests 'cause it's fun to do every once in a while. I'm like, "Wow, this is coming in kinda strangely." It wasn't like a dramatic change in performance, but you can tell with certain tools, where the GTmetrix, for example, has a waterfall so you can see exactly where some of the things might be coming in slowly. And I'm looking at this for the longest time, like, "Why is this plugin that's been on here forever causing a problem?"

And, in fact, this plugin doesn't really do much. It does stuff on the backend, and it just has this tiny little front-end portion to it. It's not a tracker or anything, so that was even weirder. It wasn't like Google Analytics or something like that hiding in there. I discovered they were importing a whole bunch of font files that were never, ever being utilized. They were being imported And I was like, on the front end. "You gotta be kidding me."

Zach: Even though they were just being used on the backend for the ad, yup.

Robert: Well, they weren't even being used on the backend; they just weren't being used. But the default for that plugin was to import a bunch of non-Latin character set fonts 'cause it supports multiple languages. And I would have literally never, ever discovered or found that if I hadn't been load testing. I mean, because it wasn't like dramatic, but it was enough. There was just something that seemed off, and I was just like, "Why is this like 0.1 second slower than it should be?" Yeah, I'm crazy that way, but it was-

Zach: So am I. I did do an entire series on running a sub 800-millisecond WooCommerce site that I spoke at a number of WordCamps about, so, yeah, it's crazy. And just a simple change, like you said, could do so much to modify your speed. And I'd like to take it just a step further. So the load testing tools see an external view, right? And they show you what's happening in response from the outside world, but you also need something that tells you what's happening inside your server. So using something like an application performance monitoring tool on the server side, my favorite is New Relic, and seeing how PHP is executing and how database calls are happening and seeing server metrics that you don't get from that external view and being able to take the two and marry them together into one overall view of how the site is performing is a phenomenal thing. And it'll change your life in a number of ways.

Robert: I can't magically depend on my hosting company to be doing that for me?

Zach: No, no. Most of 'em are, yeah, most of the top tier WordPress hosts are really good, but they don't write the code that you're using and the plugins you're using, so there's no way for them to know what garbage you're putting into your site. And I'm not saying all plugins are garbage. I'm saying there's a lot out there, and in an open-source community, you never know the quality of what you're putting on your site unless you test it.

Robert: I'll ask this one of Lauri. Okay, so, yes, test the sites. That's great. Is there a way for developers to uniquely test those plugins that are being utilized? Is there some magical way, if I have a plugin developer, to be like, "Well, I need to test version 1.2 performance versus 1.3 performance on that plugin”?

Lauri: Well, I think you just need to, so I guess you just need to have different environments, maybe a staging environment test. They do different plugins there and then load test them. And we like to always test the whole thing together. You could just test maybe the one plugin, but it's always best to test the whole complete solution, your whole site, and then just see what the performance is there. But I think one of the problems with many apps, that they just have the production environment. They don't have staging. They don't have a Q&A environment. So they just, when they do an update to their site, they just update the production site directly, which is quite reckless. And there is a better way, but there's a lot of education needed to be down there.

Robert: I don't know anyone who does that. You must be kidding.

Zach: And I'd go a step further and say that the most important part about those staging and QA environments is that there is parity with the production environment, not different, but they can't be different. 'Cause if you're load testing a staging environment.

Lauri: They always think about that.

Zach: I know, I know. And, yeah, if you're load testing a staging environment, you're not load testing what your production environment looks like unless they're identical. First, they always say it's totally identical. And then when the tip that the environment crashes, then they say that, "Oh, actually it wasn't." Something like.

Robert: Okay, I assume you can load, you know, speaking of staging environments, with the tools from Flywheel and Kinsta. You can have that super desktop local environment which could be your staging. Can you use load to... I'm gonna ask Zach. I could see you roll your eyes all the way back here.

Lauri: Probably that's not similar as your production hosting environment totally. Just running, though, try it from your laptop, then it's not good.

Robert: But my question, correct, but if my laptop hosting, staging, hosting development environment actually does perform okay, shouldn't I have an expectation that it'll be much better on production, or no? Or is that just, I can't make that kind of assumption?

Zach: Generally not, just simply because your local environment, if you're using something like Local by Flywheel or any of the other tools out there, even something like the Laravel tools or something that would create a local environment that can run WordPress. Those server configurations first aren't going to match what you're running in production at all in most cases. And second of all, they're not going to match the network traffic piece, and that's where load testing becomes really interesting. And seeing what path is this traffic taking from all of these locations that it could possibly be coming from, and what hops are required to get to the server? How is DNS resolving?

And all of these little things that you would think wouldn't matter at all. I mean, there's this thing called, I believe it's OCSP stapling, which is a way to staple your certificate result from your SSL provider to an initial response so that once it's generated, it can be cached for a while. So normally when somebody comes to your site, they get to the site and then your server says, "Hey, I have an SSL certificate. I need to go contact my certificate authority, and I need to get my certificate back from my certificate authority." And then the certificate authority has to do a look up, and then bring the certificate back to the server, and then the server serves it to the browser. So OCSP stapling allows you to, on the server level, cache that certificate authority response for your period of time so that you eliminate a couple of hundred milliseconds of that round robin with the certificate authority. These are all very interesting things, but they're all related to how DNS resolves and how the server forms its initial response as part of that time to first byte.

Thanks to our sponsor PayPal. PayPal offers Buy Now Pay Later options that your clients can use to help increase their sales on their WooCommerce shops. They gives store customers more purchasing power through flexible and transparent choices in how and when they pay.

So offering those payment options is good business. Did you know that 64% of consumers surveyed say they are more likely to make a purchase at a retailer that offers interest-free payment options. And 56% of consumers that responded agree that they prefer to pay a purchase back in installments rather than use a credit card.

Well, this seems like a no-brainer to me. Clients can grow their sales and get paid up front with no additional risk or cost.

All you need to do is download the PayPal Checkout extension on the Marketplace at WooCommerce.com. Just head on over, click marketplace and search for the PayPal Checkout. Suggesting that to your clients will certainly open up sales opportunities for them.

Thanks for PayPal for being a community sponsor at Do the Woo. And now back the conversation.

Bob: I'm gonna play the devil's advocate here, and I'm gonna lay something, especially on Lauri and Zach. Let's say Bob says, "The heck with podcasting. I just wanna become a eCommerce... I'm gonna build WooCommerce shops for people." And because we're talking about bizarro world 'cause that's never gonna happen, but I start getting into it, and I'm putting up client sites. And they have 10 products and maybe some have 20, and I'm kind of easing into it. I wanna know, I started, I listened to this and I started thinking, "When do I need to start doing this?" I feel like maybe I have a simple site. In my mind, I'm gonna say, "Okay, I'm running, you know, nice clean theme." Maybe storefront, I have WooCommerce.

Maybe I have a total of 10 plugins on there. Everything's going cool. My client has 10 products. This one has 20. This one has maybe 25. Is this something I should be preparing myself for or preparing my clients for? Or, you know, I don't look bad. Or is there some breaking point along the way that I need to start seriously looking at, you know, "We need to do this or..." I guess it's a simple, simple site. Is it still good to load test it for my clients? And I mean simple by very minimal stuff.

Lauri: Yeah, even if you were to have just a simple one pager, you should actually load test it if you plan to get any kind of meaningful traffic there. So if the site is gonna be that nobody's gonna visit anyway, so it doesn't matter, then you don't need to load test. But if you expect to get visitors there and a lot of concurrent users, then you should load test. And it doesn't matter if you have one product, 10 products, or 1,000 products. It's the amount of how many people are coming at the same time to your site. That's the bottleneck. That's the problem.

And there was no hosting provider saying that we can handle 1,000 concurrent users. They don't tell that. They tell that, "Okay, you have a one gigabyte of disc space," and you have this and this and this, but they don't tell you how many users can handle there. So how big is your store? If you have a physical store, it's already here. You can get 50 people get in at the same time, or 100, or if you have a bigger, like a supermarket, could be even 1,000. But with your eCommerce store, you don't know, so you should test it. And even if you think that it's okay, it's just starting, maybe it's good to testing to know the limits. Then you know later on that, okay, if we will put some money on the marketing, we have to be aware that we can only handle maybe 200 users at the same time, or something like that.

Bob: So it's always a question of being prepared.

Zach: Right, well, and you asked two questions there, and the answer to both of them was yes. But what I would say is that there are certain markers that I would look at as indicators that it would be a good time to do a load test. One is, are you going to be spending money on advertising your store to drive traffic to it? If you're gonna spend money to drive traffic to your site, you should probably know that you're spending money that's going to drive traffic that's going to be able to stay on your site. So that's a good indicator. Have you made significant changes? That's a marker that I would say warrants a load test. Are you going to be featured in media of some sort, whether that be being on "Shark Tank" or your local news station.

Or the story that I've told for a number of years now about my friends at Oscar Mike who called me on Thanksgiving Day because they had been interviewed by Jeff Joniak, the voice of the Chicago Bears, in the Chicago Bears locker room set, about their company and didn't call me beforehand and got about 10 orders before the site and server it was on died because the server had the email server for every email that was being sent on the same VPS. So, yes, these are markers that you should really look at as opportunities for load testing. And they're not the only ones. There are significant events that happen every year, every holiday sale. If you're going to have a Black Friday/Cyber Monday sale, if your site is selling products that might be popular over Christmas , or if you happen to run a niche site where all you sell is Easter eggs, well, you should probably load test before Easter. Those are the markers that I look at as indicators for when those types of things should happen.

Bob: And I guess in reality you could think of it as who knows if somebody will drop your product in a viral video, and you don't even know it's gonna happen, and suddenly you're wondering, you know, everything's coming left and right. And next thing you know it, you're having issues and stuff. So it's, yeah. It sounds like be prepared. I mean, I personally don't think everybody's gonna... I don't have that many sponsors spots for my podcast so I don't have to worry about that on my side, fortunately, but, yeah, it's interesting stuff, yeah.

Robert: Well, and we forgot to mention the one huge, huge factor in why you should always load test no matter how big your site is: Google takes that speed into account for search engine results. So your SERP is your search engine result page or position, you know, is modified by how quickly your site is. So even with the simplest of blogs, if it's running on some horrendous shared overload server, and you're not getting that page up in five seconds, you're never gonna wind up anywhere on Google.

Zach: Wait, you mean in the hosting world, we're not supposed to put 2,000 sites on one server?

Robert: You know, just like when planes put 5,000 people into the seats. Yeah, there's overselling everywhere.

Bob: Lauri, do you, as far as the people that come to you for your service, do you, and maybe you don't even know this, do you get a lot of 'em coming to you because they've hit that wall? It's almost like they came to you, I don't wanna say too late, but they realize the need, or is there a lot more coming to you that understand, "I need this in place and be prepared"?

Lauri: Well, I think the most often they come just before like Black Friday or just before they are going to launch, and then they are really self-confident that everything will go fine. He goes, "Hey, we have AWS and Auto Scaling, so it's gonna work," or, "We have Cloudflare, so it's going to work." And then we test, and then the results are usually pretty horrible because actually, you know, it's actually quite a low number of users that average website can handle if there has not been any good performance engineer or a sys admin there, so the number could be really low. So that's the first problem, that it's always like really, really at the late, late stage that, "Okay, we are going to live tomorrow. let's just test it now so we are sure." And then we say that, "No, it's gonna crash." And then they are like, then their site, like, huge problem that we need to solve in 24 hours. So that's like the one thing, that there should always be a really good time before you have the big day so that you can actually also repair the problem.

Zach: Well, I'll even go a step further and say if you don't know if you're going to be able to handle the traffic that you're going to get, there are these services called queuing services that can set up a queue in front of your website and you determine how many simultaneous users can hit your server, and they will put the others in a queue and make them wait to get to your site. And most of these solutions are JavaScript based. There's one from Queue-it that I've used in the past. They just take over when the person first hits your site, and then put them into a holding pattern if there's too many planes trying to land at the airport.

Lauri: But, yeah, I think, but you could also solve the problem and then just serve everybody at the same time.

Zach: Oh, absolutely. Absolutely. I think a combination of the two is sometimes necessary though because even with the best optimized website and horizontal scaling across 30 or 40 servers, you could generate enough traffic to take all of those webheads down. It's hard, but it's possible.

Bob: What does this holding pattern... That intrigues me. I'm just picturing this. You're put in this little room with all the, no, I'm just kidding, but maybe a virtual room. What are we waiting for here?

Zach: Go onto Ticketmaster to try to get tickets on the day that they come out and try and beat the bots to buying concert tickets or event tickets. Those queue solutions that Ticketmaster uses... Well, they actually use Queue-it, the one that I mentioned. They put you in this little holding place with a timer that tells you. I mean, even Sony is using it for the PlayStation 5 that nobody can buy. They queue all the traffic to the site and they trickle it in.

Bob: Wow, that's amazing. I mean, I'm just picturing that. Yeah, anticipating.

Zach: Standing in line in your casa.

Bob: Just be a little bit cautious, that I think in average, that your customers might not like that solution so much.

Zach: That's very true. Yeah, I have heard of queues of hundreds of thousands of people, but those are rare.

Bob: It seems like it would have to be a product that's very wanted at that moment. I mean, it's like, this is the only place you can get it, and it's gonna be gone here soon type of thing and stuff, or otherwise, yeah, I'm gonna go look for this somewhere else. Buh-bye, you know? I don't need it right now. So interesting stuff. Well, to wrap this up, what I'd like to do is have you give one last, maybe something I haven't covered or one last piece of advice to all those builders out there that are now thinking, "My, God, I think I need to start doing this for my clients on a regular basis and get things in place." Why don't we, you know, I don't know if you have anything to add. I'll just kinda leave it open in case there's something we feel we've said it all.

Robert: I think it's load test early, load test often. I mean, the solutions are, the load testing solutions are actually really inexpensive for what you're, you know, across the board. So even if you're just doing the smallest load test, you're not gonna spend a lot of money, or, I mean, almost every one of these has a free option just to get a general idea. So there's no excuse not to use the free option and then see where you can tweak and get better at. But load test early, load test often.

Zach: Yeah, I'd even take that a step further. I would say, based on your comment, Robert, about cost, if your site goes down during a sales event and you lose a thousand sales with an average order value of $30, how much did that just cost you? Well, Supervisor, your most popular plan, your thousand simultaneous users, is just under 500 a month, right?

So if you have the potential to lose $30,000 or you can uncover problems by spending 500, which one would you take? I think it's a no-brainer, personally, for any store owner.

Bob: Simple math there. Yup, yup. That's for sure.

Lauri: Yeah, I would also add that it's actually quite difficult to host WordPress so that it can handle a lot of users. It's not a simple problem, you know? So most of your web hosting providers can't do it. You will need a lot of expertise to scale WordPress. So you'll need some help with scaling. And the first step is to load test, and then you'll figure out that if you need help, and most likely you will need help. So that's the reason why to start testing early.

Bob: All right, excellent. Well, yeah, I think this is a good preview of just how geeky the show can get. And I am going to get all the developers in here to listen to this particular episode because, yeah, this is deep, really deep, so that's good. So we like to get geeky. Yeah, I'd like people to be able to connect with you, reach out if they wanna continue the conversation or maybe even ask a question about load testing. Lauri, why don't we start with you? Where can people find you on the web?

Lauri: So just head to supervisor.com. That's our site. You can try out our solution for free. And then there's also some different plans if you want to test with bigger amount of users, and we are happy to help. We can even do a free test for your site. So just connect through my website, and let's get going.

Bob: How about you, Zach?

Zach: Well, I'm zstepek, Z-S-T-E-P-E-K, pretty much everywhere. Twitter, Instagram, all the things, including Clubhouse. And if you want to learn more about what I do, you can go to zachstepek.com.

Robert: Well, it's gonna be the names dot com everywhere, isn't it? Except for Lauri, who somehow got the best domain name, one word English dot com. You can reach me robertjacobi.com. I'm @robertjacobi on Twitter. Those are the easiest places. I'm also on Facebook and LinkedIn, but Twitter and robertjacobi.com.

Bob: Excellent. Well, that's it. Yeah, this has been a great show. Again, thanks to PayPal. Check out their pay later options for sure, especially for your clients or for yourself. And I just might drop a note here that we are going to be announcing soon, or not already announced, the Woo Builder Meetup. So kind of look at it as events. Zach is a co-organizer if you want to get really geeky with that. I mean, he's gonna be talking... I mean, this is code. This is deep into the code of code. That's all I can say. So watch his monthly meetup. Robert will be joining us, some stuff there, and I'm sure Lauri, I'll be having him in on some different things. But we're gonna have some great weekly stuff, good variety, so check that out. Just go to meetup.com and look for a WooCommerce Builder meetup, and you'll find us there. So, again, thank you three gentlemen for joining me. Good conversation.

Robert: Thank you, Bob.

Zach: Thank you, Bob.

Lauri: Thanks.

Bob: And thank you everyone for tuning in. Until next time, "Do the Woo."