How To Improve Your Hosting Performance on Adobe Commerce With Josh Ward of Nexcess

Guillaume: Hello everyone. Guillaume Le Tual here, host of the Ecommerce Wizards Podcast where I feature leaders in e-commerce and business. Today’s guest for a second short episode is Josh Ward, VP of sales at Nexcess hosting and we’ll be talking about how to improve the performance of your Adobe Commerce also known as Magento e-commerce hosting performance.

This episode is brought to you by MageMontreal, if a business wants a powerful e-commerce online store that will increase their sales or to move piled up inventory to free up cash reserves or to automate business processes to reduce human processing errors, our company MageMontreal can do that. We’ve been helping e-commerce stores for over a decade. Here’s the catch. We’re specialized and only work on the Adobe Magento e-commerce platform, also known as Adobe Commerce. We’re among only a handful of certified companies in Canada, we do everything Magento-related. If you know someone who needs design, support, training, maintenance, or a new e-commerce website, email our team at [email protected], or go to magemontreal.com.

Guillaume: So without further ado let’s just jump right into the topic Josh, how do you go about optimizing the hosting performance of an Adobe Commerce or Magento hosting?

Josh: Yeah. Happy to be chatting again on this script. I think if I work sort of top-down the first thing I might look at is, how are you leveraging a CDN? I think that’s a really important piece and is sometimes overlooked. CDN can cover a lot of evils from an optimization standpoint, certainly not unique to Nexcess, image compression tools, distribution of static files, all of those things just really reduce the load that any traffic has on your primary hosting setup. So it means you buy less resources from me and you put assets closer to the visitor. We see that as a win-win and that’s good for everybody. So CDN is really important and like I said, it makes everybody’s life a little bit easier. So that’s a biggie.

From there there’s fine tuning in the LAMP stack in general, the way you’re running PHP, the way you’re going to run Apache, those are tens of 1000s or maybe hundreds of 1000s of Magento sites at this point that we’ve worked on. We have a nice little recipe that we can start with to make that LAMP stack as efficient as possible. Apache and Nginx are one of those areas where we’ve put them through their paces several dozen times and we’ve just found Apache a little bit more compatible with some other things that we use or the tooling and things that we use. And when it’s fully optimized, when it’s not just out of the box, it’s about as performative as Nginx is, like, we don’t feel like the ease of use trade-off is worth just the little bit of performance enhancements that we get. And that’s really important to us, these are the things that we kind of think about on a daily basis.

Guillaume: So Apache wins by a slim margin?

Josh: From a performance standpoint Nginx probably wins by a slim margin, but ease of use and compatibility, Apache wins. So performance win for Nginx isn’t enough to convince us that that’s what we should be using.

Guillaume: So we got CDN, obviously, it could be Cloudflare, Varnish and whatever else you want on CDN. Sorry, not Varnish. Of course, then on caching you have stuff like Varnish, do you also want to cover that point on Magento caching?

Josh: Yeah, absolutely. I’ll start with Redis because it’s the easy one. You start caching there and we think we can do anything without Redis. Redis is kind of where it starts but Varnish is the fun piece. Varnish is the more dynamic piece there. We approach Varnish in two ways. Especially with Magento 2, the bulk of our customers on fairly similar websites we use Varnish as a plug and play. If you rewind back to 2014-2015, Varnish implementation was super complicated.

Guillaume: Magento 1 or Magento 2 or both?

Josh: Magento 1, yeah. It was super complicated. Thankfully, it is a lot less complicated now with Magento 2. So we provide some pretty basic VCLs that are plug and play and you squeeze 80% of the Varnish goodness and then you don’t have to do the 20% of the work to sort of get the rest of the way there. So we leverage Varnish in a really general way for most of our sites which I think is really helpful for smaller Magento sites if they can flip the switch and have the power of Varnish at their hands. Now, at the higher end we’re working with enterprise customers, we still get really custom with Varnish, we work with them to get really custom and squeeze 100% of the juice out of what Varnish has to offer, so that’s great. We do actually leverage Nginx as sort of a proxy, again, if you get one of our Magento Cloud packages, we run Nginx and leverage micro caching and it just sort of sits out in front of your single VM and your stores running in a single cloud instance.

Then Nginx is sitting just right in front of Apache filtering out requests and if it’s got anything that is micro cache it’ll provide that and if not, the request goes straight on to the VM. So that Magento handles that however it deems necessary and that helps a lot. I mean, that sort of alleviates maybe 30% of the server load, that’s an average, but just running that traffic through micro caching alleviates about 30% of the server load. It doesn’t really require any additional configuration from a customer standpoint or from our end and it doesn’t keep things in cache for long. You can flush it but a lot of times if you push a new update you don’t even have to flush the micro cache, it’s going to flush itself naturally and quickly enough such that you don’t have to constantly remember it’s there and you have to account for as you’re doing development, which is nice.

Guillaume: Since we’re dealing very technical, do you want to explain what you define as micro cache as part of that?

Josh: Yeah. Essentially, micro cache would be something like less than 30 seconds. So the pages that it holds in memory only last for 30 seconds. So if you’ve got one visitor every five minutes, micro cache is not playing a big role in your performance. Because by the time your second visitor comes through it’s already cleared the cache. But if all of a sudden you get a spike on the landing page, maybe you had a marketing campaign that just took off and you didn’t expect that and suddenly you’ve got 100 visitors to that one page, well, micro cache sees that. So it’s refreshing every 30 seconds and if that page gets served it gets cached and then it sits there. So people just keep hammering it then micro cache just holds onto that page. And when your traffic subsides and goes back down to normal levels to where maybe you’ve got a new visitor every 60 seconds, micro cache clears itself as it’s not using any more resources and it’s waiting for the next event. So like I said, it’s a great little side piece. It’s not a fix for everything but it does help you. Maybe you’ve primed Redis to focus on these 10 pages, maybe you want Redis to cache these all the time but your traffic spike comes from over here. Micro cache kind of bridges that gap, let’s Redis catch up and starts caching this other page and you’re back. You’re off to the races.

Guillaume: Another frequent question would be, how do I plan for a traffic spike? If I know in advance that I’m going to spend four times more before Black Friday I guess I can have a chat with my hosting company and say, can my site handle that kind of traffic and ad campaign? But what if you get an unexpected exposure through marketing and it’s sending you lots of traffic, how do you plan for that or how do you react to that to be able to benefit from it rather than not just being down or super slow?

Josh: So I would say there’s multiple things to consider and there’s always a cost benefit, how likely is something to happen? Sometimes when you’re talking about capacity and planning for traffic spikes, you’re kind of talking about insurance. Like, how much insurance do I want to buy? I don’t want to be over-insured but I also don’t want to be caught in a bad situation. So we would handle that in a couple of ways. There’s a scenario where your VM doesn’t resize, it doesn’t actually get bigger or smaller. We just provide additional resources on the fly to handle that spike. Additional resources so that you can increase the amount of PHP processes and then when it subsides then it sort of goes back down, this idea of sort of auto-scaling. It certainly has its upper limits. Another option would be to resize my VM, a single VM or one server. If I’ve got a spike I need to get bigger, but you have to reboot. The downside there is that for a few minutes your site’s going to be down so that when it comes back it’s got more resources and it can be up and be performative. So that’s kind of a trade-off there.

Another way to break out of the single, you know, ‘I’ve got a single server or a single VM and what do I do when I get a traffic spike’, is, we still rely pretty heavily on bare-metal solutions at the enterprise level. Our larger customers are still running in clustered architecture on physical servers. One of the ways that we combat these unexpected spikes is, we own and operate the data centers and so we always have hardware sitting there, what we call permis-scaled. So if we think the customer comes to us and we go, you need four front-end servers but sometimes we think you need five or six, then we just include that extra capacity because you don’t need to always run six servers, maybe, but you always need them there just in case. So we’ll include some additional servers that aren’t going to be an additional cost or at least certainly not a significant additional cost. Just have them there just in case. So if we erred on our calculations, if you underestimated how effective your marketing efforts were going to be, you know, if one of us was wrong or we were both wrong, or whatever it was, we want to make sure that there’s some additional capacity there. Because you can’t turn on hardware immediately if you don’t have it racked and ready to go. So we kind of make sure that’s the case.

Then the third way is when we virtualize clusters. So when we move that enterprise architecture into a cloud environment and then you get it load balanced, you know, VMs all over the place then you can scale vertically. You can make each one of those VMs bigger, you can add more of them, then you have a lot more options as you start to virtualize that and you can kind of go from there. Planning is always best if you can. We’ve worked with brands and I’m not going to name any specific names but we had a couple instances.

I remember back in the 2017-2018 timeframe where we had a customer and there was a news story, something had happened. It was in all the news networks and everything and they were the focus of the news story but the company wasn’t. Their product was part of what had happened, it had been mentioned in all these news stories and they just got a flood of traffic. And that’s not related to their marketing, this was traffic that wasn’t buying their product. They were just like, what’s this product that’s mentioned in this news story? So they would get a flood of traffic and we had a couple of those instances. And that’s kind of where this permis-scaled process came from. So we were like, when a customer is big enough you sort of never know what’s going to cause these spikes and so how can we help them prepare for it? So we help do that capacity planning as a ‘just in case’ and I think we’ve gotten pretty good at figuring out what’s needed there.

Guillaume: Okay, so we’ve covered the scalability which is an important part of having an optimized hosting performance, you don’t want to have a slowdown or downtime there. You already covered the CDN and leveraging caching, Redis, Varnish and so on, you talked about right-sizing to not overpay or under-pay. Just right-size your hosting hardware and capacity. I can also think of Cron Jobs that we can perhaps cover and any other ideas that you have. If you can run through that like a bullet point or checklist of ideas on how to optimize a hosting?

Josh: Yeah. Crons are great. When you’re running Cron Jobs, how many you run and when you run them becomes really important. Those are things we typically like to address in the migration process because if you’re running a bunch of Cron Jobs to update product SKUs in the middle of the day when most of your customers are buying from you that’s not great. So we have to figure out how best to handle that and how necessary are those Crons to run anything database related. I think a lot of folks think less about what sort of third party systems they have plugged in that are reading and writing things to their database. It might be an ERP or whatever sort of inventory system or PM they might be using or whatever it is, we’ve a bunch of different things there. But that’s potentially also a choke point for resources and there’s ways that we can plan for that. You could change some things with your business or we could just architect the solution a little bit differently or some combination to overcome that.

Certainly admin users is another piece. Magento 2 is way better at handling admin users than Magento 1 was but we still run into customers whose sales departments, their fulfillment departments or sometimes their customer service departments are all logged into the backend of Magento at the same time that orders are coming in. And all those users are really dependent on server resources so then how do we kind of fence off all your internal users and their resources and then your usual visitors, that becomes another one. Balancing redundancy with performance, especially from a database standpoint, is always really important. Having two database servers is great but making sure that as you’re writing to the secondary database you’re also not sacrificing performance on your primary database. That becomes a really important balancing act, knowing when and if you should add a third database into the mix and cluster that. But yes, it’s a much sort of bigger build, bigger consideration.

Guillaume: Yeah. That’s a huge build. And how would you split the database? Like, you would say, I want customers here, orders there, how do you split it? When and what’s the decision on how to split the database when it gets really huge?

Josh: A couple of considerations. One, like you said, which tables might you split out? That’s based on what needs the most resources or needs the most dedicated resources? If you get a bunch of new accounts coming in, from a customer’s standpoint, but not a lot of sales, let’s say you’re a wholesaler or something and so people are browsing pricing and you are more B2B and they’re calling in to place orders, you know, lots of scenarios. Yes, we’re based on the business use and a little bit less on, ‘this is how we always do it’. And then there’s replication with three servers. Even if you’re not splitting tables off across those three, when you have three servers and you’re trying to do some sort of real time replication there, you’re going to lose a lot less performance with three than you would with two. With three database servers you get much closer to real time replication than you can with two without sacrificing performance.

To get real time replication across two servers you have to sacrifice performance on your primary. Because it’s receiving rates and it’s providing information back to the system but then it’s also replicating itself over here and so you take some performance hits. I’m not a database architect so I don’t understand all the things, but when you have three you’re able to do that in a more efficient route where essentially you have two primary database servers and they’re taking turns writing to the secondary type of setup. So we don’t have a ton of customers that are running that.

Guillaume: No, you have to be huge to need to charge databases or stuff like that, there’s demand for that sometimes. So that’s pretty good coverage. Anything else top of mind to optimize hosting performance?

Josh: Yeah, not to do this to you again but I’m always going to point back on the development piece. Work with a great developer because the more efficient your code is the less uniqueness you need for me as a hosting company. That’s going to save you money and time and effort in the long run. Paying a little bit more upfront to work with someone like yourself pays huge dividends in the long run. Your total cost of ownership I think goes way down.

Guillaume: Big time. Because the worst case scenario that we’ve seen in say, how long is it going to take to do that change there? Well, let’s see four hours in a normal setup, but then it’s built so terribly then it’s like, actually it’s going to be like a day and a half. That’s three times the time because that thing is spaghetti, and that is terrible. And then of course it impacts loading and affects the user experience. Another one is the Google Core Vitals score. It’s very popular since it came out not that long ago. Don’t go crazy about chasing the 100% score, just improve it a lot. Because that doesn’t give you a sale. It’s just one ranking signal among many for Google to give you a better ranking on Google which can then give you some sales or some traffic to SEO. But it is definitely an important one especially if the user truly feels that it’s a quick fight when you quit. You fear that it can hit back more than having a score.

Josh: Yeah.

Guillaume: That’s a pretty good one. Unless you think of anything else I think we can wrap up this episode here.

Josh: Yeah, I think I’m good.

Guillaume: Okay. So Josh, if somebody wants to get in touch with you how do they do that?

Josh: Yeah, drop me an email, [email protected] and I am Josh D. Ward on most social platforms, LinkedIn is probably my favorite. So feel free to connect there and that would be great.

Guillaume: All right. Thanks for being here today, Josh.

Josh: Thank you everyone.