So just how powerful of a Web server do you really need to run an online store or an online course when WordPress is your CM’s? Now, that is a very complex question, but I’m just dumb enough to try to answer it in this video. Stay tuned. What’s up, everybody, it’s Dave here from Profitable Tools, and I’m going to attempt to answer the age old question of which hosting plan should I go with? Not necessarily which host should you go with, but how should you spec your server if you’re using WordPress to build an online course or an e-commerce store or both at the same time?
Now, all you, Cliff Slavens of the WordPress world out there, you know who you are. This is not going to be a completely scientific process. Right? There’s a lot of variables involved here. I’m simply going to give people a method to check and see if they’re kind of in the ballpark before they scale up their server. You don’t want to pay too little and give your users a bad experience, but you also don’t want to pay too much and end up just wasting money on resources for a server that are never being used.
Now, as I mentioned, this isn’t really about recommending a specific host, but I want to kind of persuade people who are not there already to give up the idea of the old shared hosting model where we really want to go with our businesses in twenty, twenty one and beyond is to look at the commodity providers of services for computing. I’m talking about Amazon, U.S., Google Cloud Platform. Smaller ventures like Vulture, Lynard and Digital Ocean all have great offerings as well.
These companies are all very similar in the fact that they will just sell you raw computing power and then it’s up to you to manage it and actually use it. Now, the hold up here is a lot of people are not very technically minded when it comes to administrating a server. That is pretty difficult to do. Honestly, it’s an entirely different occupation. So we are going to enlist the help of some tools. And this is where, you know, a slight plug for my favorite hosting providers will come into play.
So Cloud is the service that I find myself recommending to most people. Most of the time it’s a really great service. It doesn’t require you to have your own accounts with all of these commodity providers. You can see their partners down here. They work with all of the names I just dropped a moment ago. And what they’ll actually do is you sign up for their service. They mark up the commodity providers a little bit. You pay a little more when you go with cloud ways, but they give you a really great graphical user interface and they build you by the second.
Really. So I’m going to do some testing here. It’s going to take me a few hours to complete, but it’s not going to cost me very much money, even though I’m going to use rather large servers to do testing. And the reason for that is I don’t have to sign up for a long term contract. So cloud is really great if you’re doing some one off testing, if you just want to run one or two businesses on a WordPress website, I highly recommend checking out cloud ways.
The other option to consider is gripping, which is actually what my business uses for our hosting. For our clients. The benefit of great pain is that you pay a monthly fee, a flat fee, and then you can add as many servers as you want. The downside is you need to have accounts with each of the commodity service providers. So you’re paying two people. Then in a sense, you’re paying great pain. You’re also paying AWB or Vulture, whoever you use.
And you have to do a little bit more server administration. So if you’re dealing with an agency scenario or you have literally dozens of business that businesses that you’re overseeing, then I recommend checking out great pain. Otherwise, I’ll be using cloud ways in this video. I will have links for those down below. Otherwise this is not a sponsored video. So if you want to help me produce more content like this and you’re looking for some hosting, wouldn’t check out my links.
All right. So I’m going to go ahead and fire up a server on Clowes’ and then I’ll explain to you how I’m going to be doing the load testing for this video. So first things first. Let’s go ahead and launch a brand new server over on Cloud Ways. I’m not choose a WordPress server here. It doesn’t really matter what I call it because it’s only temporary. We’re going to be using digital ocean for this video and we’re going to be testing several things.
How does server load respond to RAM? How does it respond to CPU speed? And we’ll see how that adjusts as things scale up. So we’re going to start off with the absolute smallest digital ocean server. This is ten bucks a month. You can see that cloud ways doesn’t even want me to use this unless it’s for a staging site. But you might be surprised at the performance we can get out of this one gigabyte site. You might notice these icons underneath some of the plans here.
What these are the new faster CPU cores that are available on some digital ocean plans. So what this will allow us to do is see how CPU actually effects load performance. How many concurrent users can we have on our website with a one gigabyte site versus a one gigabyte site with a faster kind of overclocked, you know, type of CPU of a higher performance core CPU? So that’ll be really interesting to see. Let’s go ahead and launch this server and we’ll get into the testing.
All right. So my server is spinning up right now and well, this is spinning up. I’m going to go and show you one of the applications I’ll be using to do the testing. So this is Loader I. Oh, it’s a service. Sen. They do transactional email services, but Lauderdale is a really great way to emulate load on a server. Now I know that this is not a comprehensive test, but it gives us a little bit of a scientific lab to plan to see how servers respond to enormous amounts of concurrent requests without having to pay all of our BuddyBoss or maybe hire an entire Facebook group to go bombard a server and see how long it takes to bring it down.
So as soon as my cloud server spins up, I’ll be connecting that default WordPress website up to Latrelle and we’ll begin doing the testing. I’ll explain all the numbers as we go through. All right. So my server has spun up. I’ll just take you through the process of connecting it up to Lauderhill. First of all, I’m going to go ahead and get the UI for the server itself, which cloud gives me right here. I can just copy this.
You can see this is just a default WordPress website. Nothing fancy going on here. I simply want to test how it’s going to respond to a lot of concurrent activity over and again, Lauderhill. I’m going to add a new target host here. I should note that I’m using their free plan for this testing so I only can have one host on at a time. This is not a sponsored video by them. I have no affiliation with Lidderdale at all.
Let’s go ahead and verify this domain. So why do you have to verify a domain when you’re going to do load testing? Well, if the answer is not obvious to you, let me explain. When you do load testing, we’re going to slam this server with a ton of traffic. You can imagine if you had a competitor on the Internet and you wanted to slow their website down, one way to do it would be to just absolutely bombard them with traffic.
So there’s definitely security, plug ins and infrastructure out there to prevent that from happening. But, Loader, it is going to make you verify that you actually own the website before they allow you to slam it with traffic. So what I’m going to do here is just download a verification file and then I almost never recommend in fact, I never recommend doing this. But what I’m going to do is actually log into the WordPress admin and just use the file manager, plug in to throw it up on the Web server.
I don’t recommend that plug in when you’re doing anything on a production site, but for now, which is the fastest way to get this online. All right. So plug ins and you can search for file. It’ll be the first one up here. File manager. Again, this is just kind of a security flaw to have access to all of your files inside of your WordPress admin. So don’t do this unless you’re doing a silly test like I am doing here today.
Now, all I need to do is just drag and drop this file into this window and it’ll verify over downloaded audio. All right, there we go. There is the verification file. It is uploaded. I’m going to go ahead and tell Loader to check for it. Will click verify right here. All right. We’re good to go there. Let’s go ahead and do our testing now before we begin our stress testing, I want to point out that I do have some caching on on the server level as well as on the WordPress site.
I’m going to run one test with caching on and then I’ll be disabling it for the rest of the testing. So the first test is going to kind of give us a baseline of what you can expect for pages that can be cached and then other pages cannot be cached. If you’re unfamiliar with the concept of caching, which I know it’s kind of technical, if you’re not really in hardcore into the WordPress world, what caching is it makes the website load faster because instead of WordPress having to go into its database and then draw the page every single time a person requests the page, it simply goes into the database once, saves that file, and then just serves up a static file to each visitor that comes to your website.
Now, that’s great for things like landing pages or sales pages where you don’t have content that’s changing very often. If you change it, you can just refresh the cache. But for other things like ecommerce checkouts or online course quizzes, those things are dynamic. You don’t want every visitor to have the same cart when they check out. You don’t want every visitor to get the same results from their quiz. Those pages cannot be cache. So that’s really what comes into play when you’re talking about how many people can be on your website at any given moment.
So we’ll do our first test with caching on and then we’ll turn it off for the rest of the testing. All right. Let’s begin a new test over unloaded audio. So here is how I’m going to set up the test. I’ll just call it demo. And the test type I’m going to choose is maintain client load. So what’s going to happen here is over the course of a minute, I’m going to be able to increase the number of clients that are hitting the website at one time.
At a certain point, our website will reach a critical point where it’s not optimal anymore. It’s not going to be a good user experience. It doesn’t necessarily mean that the website will break. It will just feel sluggish. So Google has a specific metric they’re looking for here. It’s under two hundred milliseconds response time. So what that means is when you click on something on the website, it has two hundred milliseconds to respond back to the. Person who clicked after that, Google starts to think that the website is maybe a little bit slow now, in all actuality, most of the top performing websites are between two hundred and three hundred milliseconds response time.
But as long as you keep your response time under five hundred milliseconds, you’re going to be just fine. Again, the website will still work. It’s just going to be one of those sites where you click and then you sit and you wait and it’s frustrating and you dread having to go to that website because it’s not a good experience. What we want to do is balance out having a snappy website as a joy to use, but doesn’t have just a ton of resources that never get utilized.
All right. So for this first test, remember, I have caching on I’m going to test up to seven hundred and fifty clients. This is a one gigabyte server, ten bucks a month over on cloud ways. If you’re buying it direct from the vendor, it’s going to be closer to five bucks a month. All right. Let’s go ahead and run the test. All right, so the test has just begun, we’re about five, six seconds in and the numbers that you’re seeing on the chart, they’re going to be constantly changing.
So I can’t really pinpoint them till the test is done. But the numbers are going to be seeing are how many clients are on the website versus the response time. So right now, we have hit about 300 clients on the website and the average response time is right around one hundred and twenty five milliseconds. So I will get back to you when this test ends in about 30 seconds. OK, so the test is all done, let’s make some sense of the numbers.
So what we’re looking for is when the average response time goes above 200 milliseconds. Now, remember, some are going to be higher than that and some are going to be lower than that. It’s just the average time at that point. So we’re at 197. Thirty seven seconds into the test. And if I check the other line, that’ll tell me how many users I have at thirty seven seconds. So four hundred and seventy nine clients at the same time accessing the website.
So does this mean you can have four hundred and seventy nine people accessing your online course at once. Well yes, kind of maybe. Remember not everyone is going to be clicking in action at the same time in some actions are going to require more than one engagement from your server. So these numbers are rough, but we’re just trying to get a ballpark number. Remember, this is for cached content, so it’s not going to work for all of the pages on your website by the end of the test.
When we had reached seven hundred and fifty clients, our average response time was three hundred and fifty two milliseconds. Now there’s some other data to point out here, the minimum response time. So when it was just getting started, I would assume the minimum response time was 14 milliseconds and the highest response time that I ever received was six hundred and fifty two milliseconds, which is still bearable. I mean, honestly, we’ve all clicked on a page and it’s taken a second to load before we’re talking about a little bit more than half of a second.
It’s not the end of the world, but we don’t want our website to respond like that with every single click.
So bottom line is, I can stay under two hundred milliseconds and serve up to four hundred and seventy nine clients on this cached page. If I’m just worried about staying under five hundred milliseconds, I can do seven hundred and fifty plus.
All right. So I’m going to turn off caching for the next test. But you might be thinking how can I test the response time of my site without just bombarding it with tons of traffic? Well, you can use a tool like Kingdom and what you want to look for is the time to first byte. That’s going to be the same metric as the response time. All right. So let’s go ahead and disable caching over uncloudy days here. I’m going to do this first at the server level.
So I’m up here in the server tab. I’ll click on my server and then I’m going to go down to manage services. And here I can see I have the varnish caching on, so I’m going to go ahead and disable this. All right. So varnish caching is now turned off and now over at the site level, I’m going to go ahead and go into my plugins and Clowes’ by default will install their Briese plug in, which is just a page cache.
So we have two different levels of caching. I’m going to disable this now. I should have no caching going on on my website at all. Let’s go ahead and rerun the test and see how this affects the results. I’m going to edit the test before I run it because we will have to have some different numbers going on here. All right. So instead of zero to seven hundred and fifty clients for noncash content, I’m going to do zero to 50 clients.
We should see quite a different response from the server here. Now, remember, this is going to be the more critical test for our site because this is going to be things like your checkout page. So if you’re doing a big promotion, a big launch and you have lots of traffic going to your checkout page, you don’t want that to be slow or, you know, God forbid for it to crash. All right. Let’s run this test with 50 clients over the course of one minute.
All right, so the test has just begun. About 20 seconds in and our average response time is already well over the 200 barrier that Google expects to see from us. I mean, see, we crossed this about 10 seconds into the test. So I’ll give you the final numbers here in a second. All right. So the test is complete and at 11 seconds and we hit one hundred and ninety six millisecond average response time, that’s going to be equal to ten clients concurrently.
No, it’s not really that bad. If you have a ten dollars a month website and you can still serve 10 concurrent users, think about your online course. How many people are actually logging in at any given time unless you’re extremely successful, in which ten dollars a month isn’t really, you know, going to be a relevant number, then that’s pretty good, right? Because if you have one hundred users, 10 percent logged in at any given time, unless you have live events planned, that’s probably, you know, a pretty high number.
So price tags on our ten dollar month server without caching. If you want to stay under the two hundred milliseconds threshold for response time, they’ll be able to serve about 11 clients per second. If you’re willing to bump up to the five hundred millisecond range, you’re looking at the 24 client per second range.
All right, let’s move on. We’re going to scale up here. I’m going to go over to vertical scaling inside of cloud ways and we’re going to move from a gigabyte server to a one gigabyte server with faster course. This is going to cost me an extra two dollars per month. So is it worth it to go from a ten dollars a month plan to a 12 month plan when I’m not getting any more RAM? Let’s find out. So the scaling just takes a few seconds.
I’m going to pause the video. I’ll be right back. All right. My server is now scaled up to the one gigabyte plan with faster CPU scores. Let’s run another test. I’m going to keep the settings exactly the same here since the one gigabyte plan kind of struggled around ten or so clients. So I think we should be fine with zero to fifty again. Let’s run the test. All right. So the test is underway. We have about ten seconds left here and then we’ll analyze the results of this newer server with faster CPU’s, but the same amount of RAM.
All right. So interestingly enough, this server actually performed a little bit worse than the first one. Now, this is one test. We should really run this several times at each level to get an average result, because that’s just how computers work. But I can see that I passed the two hundred millisecond response time about eight seconds in which was faster than the previous test, which was around eleven, I think. And at eight seconds we’re only serving eight clients.
So on our twelve dollars a month server, we actually got slightly lower results than just our ten dollar a month server. Don’t be too surprised here. It’s silicon. Sometimes you get really good chips, which are first server might have been. Other times you could get underperforming chips, which this certainly could have been as well. So we’re looking at the two hundred millisecond threshold.
You can hit about eight clients per second. You want to stay at that five hundred millisecond threshold, you’d be able to serve about seventeen clients.
So what if we doubled our RAM? Let’s go back to vertical scaling here. I’m going to move up to the next plan, which has these slower CPU cores, but it has twice as much ram as the very first test. This is getting a little bit more expensive. It is twenty two dollars a month. Let’s go ahead and scale this up. All right. My servers all scaled up. You can see I’ve got two gigabytes of RAM here.
I would hypothesize that I should see about twice as many concurrent users or concurrent actions to the server before things start to pass are 200 millisecond thresholds. We should see about, you know, twenty three twenty four concurrent clients before we pass that threshold. Let’s go out and test it out, though. Given my hypothesis, I’ll keep the settings of the test exactly the same zero to fifty clients in one minute. Let’s run it and the test is underway.
All right, the results are in, and quite honestly, I am shocked they didn’t change at all. So we are at 194 milliseconds over here. And if I check how many clients it is, it’s 11 seconds roughly where we are at war for our very first test and 11 seconds, that’s 10 clients per second. So that is exactly, I think, the numbers that we had on our very first test and a little bit higher than we had or the faster CPU core.
So we’re not really seeing any difference here with a faster host. This is not what I expected. So at the twenty two dollars a month server, we’re just not going to be able to serve that many more clients than we would with a ten dollar or a twelve dollars a month server over unclogs. So we’re looking at 11 clients under that two hundred millisecond threshold. So if you want the fastest website, twenty bucks is probably not going to be enough to spend on your server.
But if you’re OK with extending things, we did actually see an increase here up to 500 milliseconds response time. We were able to hit 26 clients per second. So that is not nothing, but it’s not really the gains I expected to see.
All right. I’m not going to quit here. Let’s beef things up a little bit further. We’re going to go up to the two gigabyte plan with the premium faster course. This is twenty six bucks a month. The scaling is happening now. Each time, by the way, I’m cutting out about six or seven minutes. Well, the server scales up and then after that, there’s about a one or two minute delay where cloud always seems to be assigning it a new IP address or reattaching the domain to the existing IP address.
So I think what they’re doing after digital ocean level is actually cloning the server and then moving the IP over. And it’s a little technical, but if you’re wondering how this is happening, they’re not just vertically scaling up the instance because you’re not able to switch back and forth between the faster CPUs and the slower CPU’s if you go to digital ocean directly. So cloud ways to work around that has cleverly figured out a cloning solution where they can just detach IPS.
All right. So we’re back up and running with these scaled up server. We’ve got two gigabytes of RAM still, but we’ve got the faster CPU scores designated by this premium tag. Let’s go ahead and run another test. Hopefully we actually move the needle a little bit here. I would have expected it, maybe even with the first upgrade. So let’s go ahead and rerun the same configuration. We’ll have fifty concurrent users over the course of one minute.
All right. So the test is done. And boy, am I confused because at two hundred milliseconds we are still right around that nine second mark. It’s actually even a little bit less. So once again, our faster CPU course have underperformed the regular CPU course. It doesn’t really make a lot of sense, but if you’re trying to stay under that 200 millisecond response time, you’re going to be able to serve about nine clients with the twenty six dollars month server.
And if you want to hit that five hundred millisecond threshold, you’ll be able to hit about twenty clients per second. So at this point I started to get a little bit suspicious. I wasn’t really seeing the increases that I expected as we scaled up our server. So what I decided to do was go ahead and set up a website over on Digital Ocean, directly bypassing cloud Waze altogether. This way we could take their tech stack out of the equation and actually see if they were helping things load faster or maybe they were slowing things down.
That’s what this test is. Let’s cut to right now.
All right. So same settings as before. We’re going from zero clients to fifty clients over the course of one minute. No caching this time we’re going with digital ocean directly running without any sort of infrastructure in between. Let’s head and run the test. All right. The testing is underway. All right, so the results are in and I would actually say the digital ocean server performed worse than using cloud waves. We had a big spike in response time kind of in the middle of the test, like the server couldn’t keep up.
It might not be configured as well right out of the box. I’m trying to limit any sort of interaction I have to do with the server administration because I think that’s kind of what cloud ways should do for you. So right here we had a ten second spike where the average response time was almost two seconds. Right, like one point seven seconds at the at the peak year. So really quite a big spike, but really decreased performance here. We’re looking at, you know, about seven, eight seconds of load time, which is going to equate to about seven or eight users over the course of the test.
So at seven seconds, you have seven clients. At eight seconds we have eight clients. And that’s really where we’re passing that two hundred and thirty millisecond range. So who knew? But Cloud was tech stack is actually decently optimized. If you install WordPress directly on Digital Ocean without any optimizations just using their app, you’ll be able to serve about seven clients before you surpass that 200 millisecond response time. If you go up to five hundred milliseconds, you’re looking at about 12 clients per second.
So with that established, let’s head back over to cloud ways and see what the next level up has entail over there.
All right. So let’s scale up again. Are we going to see any sort of increase in our servers behavior at this point? I sure hope so. Let’s go over to vertical scaling, and I’m going to move this up to the four gigabyte a month plan. This is 42 bucks a month. Let’s see what happens. All right. So we’re back with a four gigabyte server. Without further ado, let’s go ahead and run this test one more time.
So zero to 50 clients in one minute. Let’s go to it. All right. So we’re all done with the test. And once again, not a huge boost in performance, about 11 seconds and we’re hitting the same results. So it’s very interesting to me that it doesn’t seem to matter how big the server is. It’s pretty much getting killed at the exact same time. All night killed is getting slowed down at the exact same time. So there are definitely reasons to upgrade to a 42 dollar per month server.
But it turns out that time to first byte or response time is not one of them. The results are going to be basically the same. 200 milliseconds will get you about 10 clients and staying under five hundred milliseconds, you’ll see about twenty two clients.
Are we going to do this one more time? Move up to the four gigabyte faster CPU version. Let’s test it back over to vertical scaling or gigabytes premium CPU’s. We got fifty bucks a month here. Let’s scale up. All right. We’re back with a four gigabyte upscaled server with a premium CPU, the faster CPU course. Let’s go ahead and rerun the same test. All right, so the tests are in and finally, we’ve got some real results this time, we made it to about 24 seconds before we had an average response time of 199 milliseconds, not crossing that 200 millisecond threshold set by the Google overlords.
And at that point, you know, we’re at right around 21 clients or so. Overall, you can see the slope of this line is very, very steady and it never crosses five hundred milliseconds. So it has finally some results. The fifty dollars a month server will basically double the number of clients you can serve before you cross the 200 millisecond response time threshold set by Google. And if you are willing to suffer all the way up to a five hundred millisecond response time, you’ll be able to hit more than 50 clients per second.
So let’s say you have a 50 transactions per second, like 50 people checking out through your e-commerce website and you’re OK with that half second load time. You’re going to be in pretty good shape with a server like this because that would be approximately 3000 transactions per minute. And that’s going to be a lot for most stores.
So here is a final comparison chart. You can see there are a few sweet spots. By the way, I did remove the digital ocean server from this comparison. I wanted you to be able to see all of the cloud ways plans compared with each other. Now, a few more disclaimers here. So you don’t, you know, go into this blindly tech stack that you choose will greatly affect the end result of your server. Just installing things like Woo commerce and LearnDash is going to put a certain strain on your server.
At that point, you might really greatly benefit from seeing extra CPU cause or extra RAM available to your server. I think once you get an alumnus on there, you’re probably going to want to have at least two gigabytes of RAM on your server for it to be a good experience just for you working on the back end. But again, that’s up to you and your budget. I think most businesses are going to want to go for that. Fifty dollars a month server.
And if you’re just getting started, feel free to start off with a ten dollars a month server. As you can see, it’s going to be just fine to get your first few clients.
All right. So hopefully this testing has been helpful to you and you can see the impact that RAM and CPU speed has on the performance of your website. You also have a little bit better idea on what to look for when you’re doing speed tests. What are the important numbers? Everybody always looks for page load time, which is important, but response time is also equally as important. That’s going to do it for this video. If you want to check out some of the hosts that I recommend, click the links down below.
That is affiliate links so that you get a little bit of a kickback when you do that. Otherwise, make sure you subscribe to click the notification bell and visit the Facebook group. I’ll see you in the next video.