High‑Performance WordPress: Scaling Without Sacrificing Speed

Zach: Hey everybody. Zach Stepek here with Carl Alexander for yet another episode of the Woo Dev Chats here on Do the Woo. Carl, how are you doing man?

Carl: It’s good. It’s rainy here. I’m in between travels. I’m laying low till WordCamp US essentially in Montreal.

Zach: Yeah. That’s going to be a good time. I’m at the conference hotel, so that’ll be fun.

Carl: Yeah. Same.

Zach: Nice. Yeah. I’m looking forward to seeing the community, seeing everybody. Having a lot of great hallway chats. So today, as usual, we have a guest that we’ve brought with us and today we have Justin Mazzi from A2 Hosting. Justin, how are you doing?

Justin: Doing pretty good. You got me out of the morning leadership meetings, so that’s good. Get to be a little more casual. But otherwise it’s pretty warm and humid, but not too bad.

Zach: Now, your job title is Chief Technology Officer. We know that sometimes that means a lot of things. What’s in your day to day?

Justin: Well, I work pretty closely with the software development teams and the engineering teams. A lot of mentoring. I still code actively but not so much at work. So really just making sure projects are staying on task, making sure they’re meeting the asks of the leadership team. But I’m still close enough to the code that I can help with architecture decisions, things like that but I generally like to leave that to my teams to do.

Zach: Very cool. And this all came about over a career of moving ever closer to those C-level roles. It looks like you did some work at Site5 and some work over at Envato, so you definitely have made your way across the industry and have a great background. Looks like you’re from Pennsylvania as well, right?

Justin: I am. I’ve been here most of my life, but shortly after I got married, we lived in upstate New York above Albany for about 10 years, but had to come back after we had a couple children and no family around to help us out, so we’re back in the area.

Zach: Yeah. Having that built in support system is really important with kids, isn’t it?

Justin: It is. It’s amazing how hard it is to find somebody to watch four kids, but I don’t blame them.

Zach: Yeah. I have two, but one is 20 now and the other is eight. So there was enough of a gap that we really only had one that needed to be watched at a time, so we were very fortunate there. So at A2 you guys are always working on new stuff. What cool stuff do you have on the horizon?

Justin: I think the most exciting project for me is what we’re calling Turbo Hub. We are probably one of the larger hosts using WHMCS to run the billing. And there’s only so much you can do in WHMCSS for customization. Some of that code is ionic coded, so you can’t really do anything with it. So we’ve taken an opportunity to basically build some APIs into WHMCS so that we could have our own control panel and that’s what we’ve been working on.

Carl: I can’t even pronounce that for those who aren’t familiar.

Justin: I don’t even remember what the acronym stands for I’ve been saying it for so long, but I believe it’s web host manager control system, but I’ll have to double check that. But it was one of the more complete solutions around hosts that are using web host manager and cPanel. It integrates with the APIs, things like that. Handles provisioning, all that kind of stuff. We’re really just trying to use that more of an engine these days and trying to take some of the responsibilities away from WHMCS and put more custom experiences in front of customers. And Turbo Hub, we’re using that with our managed WordPress product and that just gives you a lot more controls on what you can do with your websites and we’re really trying to build this for agencies. People that build multiple websites, have to manage multiple websites, manage access, all that kind of stuff. And since WHMCS doesn’t have that support and we have the right people right now, we’ve decided this is the time, let’s do it.

Zach: Nice. And it looks like you offer both managed and unmanaged plans, which is cool because you’re letting people choose their own way. Choose their own adventure through the system.

Justin: Yeah. We have a lot of do it yourself customers. That’s still a really big part of our customer base, so a lot of people still will go for WordPress. But as we build better tools, I think we’ll have more people choosing managed WordPress. It’s a little bit more expensive, but with the control panel we’re adding, I think the value will be there.

Zach: That’s really cool. It’s always neat to see that kind of stuff happening. And we talk a lot about the tech side of things here, specifically around WooCommerce and a lot of scaling WooCommerce and running really high capacity sites and that’s a really hard thing to do well. But it seems that your plans seem pretty well set up for running higher capacity sites when needed.

Carl: I’m curious on your hand actually. There was no pressure from other vendors to build something to pressure … I can’t do this acronym man.

Justin: WHMCS?

Carl: Yeah, WHMCS. To build something like that. That seems like something a lot of you their customers seems to need right? There was no interest from them to build something like that?

Justin: Well, WHMCS is owned by WebPros and WebPros also owns Web Host Manager and cPanel. Web Host Manager is doing a lot of work on that to add what’s called WordPress toolkit. And there’s a lot of stuff in there where they’re addressing it, but it’s not part of their billing system. We are using it a little bit on our end, but more from an API standpoint. So I think they are trying to solve that. I would imagine at some point we’ll see some of that move its way back into WHMCS, but we’re trying to stay ahead of that. And again, we don’t want to really be pigeontoed to what they’re building. We want to build it the way that we want to build it. We have a lot of people that have had this experience and done this before at other hosting companies that came along with me here and we have a pretty good idea of how we want to do it and we think we can do it quicker than they can.

Carl: Yeah. I was just curious. Because that seems like a need that a lot of hosting companies must have to offer more bespoke admin and user account experiences versus I assume it was very just standardized for everyone. If you just logged in to anybody that used that solution, they all look the same essentially.

Justin: Yeah. I don’t think there’s many people using it at our scale, and so we’re probably an outlier on that platform to be honest. So I think for most people using it, it’s probably a pretty good solution. It’s just that when you want to really get custom and take on more responsibility yourself, you really have to invest some time in understanding how that system works behind the scenes and you really need some experts in WHMCS to leverage that. I’m not sure that most companies are motivated to do that, but we are at our size. We’ve done what we can in WHMCS with their hooks and their limitations, so now we have to take that next step. I wouldn’t be surprised if WHMCS ran with some of our ideas and I wouldn’t be mad about it either.

Zach: It’s interesting because not a lot of people know this, but goWP behind the scenes powers all of their business with WHMCS because they started with it when they were still an agency and they were running hosting for their customers. So they just continued using it as they transitioned to their service model and they’re still using it for their recurring billing to this day.

Justin: Yeah. We’ve always been an integration company where we’re taking different solutions and piecing them together, but we’re shifting a bit and starting to invest more time and just building our own tools. So I think that’s why we got as far as we did with WHMCS and haven’t moved off of it because we were really just working on integrating other great technologies.

Zach: Nice. So we were starting to talk about WooCommerce and how WooCommerce factors into hosting and what exactly that means across a host like you where you have both these managed and unmanaged plans. How do you approach WooCommerce sites that are starting to scale beyond your shared plans?

Justin: Yeah. WooCommerce Express is probably a good example of somebody who’s doing more specialized stuff and competing with someone like Shopify, but they’re priced a lot higher than just a normal hosting plan with WooCommerce and for good reason because it comes with a lot of good tools to build and manage that store experience. And then that’s your main focus of your business and if you don’t really want to invest time in the rest of the website, it’s probably a good solution. But if you have more to your business than just products you sell, for example, then one of our unmanaged products might be good for you and you’re going to spend less and you’re going to have more tools available. If you want to move up and you feel like, okay, this isn’t a good solution for me, then that’s where our managed solutions come in. And we have everything from shared, to VPS, to dedicated and we can help you scale all the way through all those different parts of growth in your business. So I think it’s a lot about where the customer is in their business and what they need. I think most people can get away on just a shared hosting account and save some money to put towards other things. Especially a new business that’s just starting out.

Zach: Yeah. Until you get to that point where those inserts that happen when you get a traffic event start to pile up. That’s when things get a little hairy. Burstability is the trick with something like WooCommerce because as things start to get mired up in the adding orders to the database, if you don’t have high performance order storage enabled or if you start getting a lot of traffic that’s searching all at the same time and you’re still using SQL for powering your search, those all can cause some serious problems with database access. So that’s where I was getting at is what’s the path for people where shared just doesn’t work anymore and they need to move beyond that?

Justin: Yeah. It’s always an interesting problem to solve because WordPress, it’s single threaded. It’s not cloud aware so you really be aware of that when you’re building out these plans. And really the easiest solution is just a more powerful server. So we’ve really taken some time into testing a lot of different hardware and our AMD EPYC dedicated servers are very performant. I’m not aware of anyone that’s been moved to one of those servers and had problems scaling that they didn’t have money to pay for more servers. At that point if your store’s that busy, hopefully you’re making enough money to be able to support that infrastructure. And so that’s been my experience with it. But most people jump from shared to VPS and that’s always an interesting move because depending on what they pick for a dedicated server, because WordPress is single threaded, they might have a different experience on shared than they did with dedicated because that server was faster, technically, clockwise. And then on the dedicated plan, it’s not as fast, but it is more consistent and they’re not sharing resources with people. And at that point we can begin to help them tune and optimize the server so that it can be performant for them and you’re not battling against other people on the server.

So the challenge is always moving them to shared, helping them understand the expectations of VPS that maybe it won’t be quite as quick, but you’re going to be able to run your site consistently and it’s not going to go down even if there’s a burst in traffic. Really we have a lot of monitoring in place and things like that so we can let the customers know, “Hey, you’re getting close to your resources. Before this is a problem, you might want to upgrade to something else.” Going from VPS to dedicated is quite a jump so we do our best to try to optimize them on VPS before we do that because it is a bigger jumping cost than going from shared to VPS.

Zach: And it looks like you have … Some of your VPSs are on the turbo architecture as well so that’s probably a good place for something that needs that CPU, that needs more workers, that needs to be able to scale to handle those larger traffic spikes without needing to go all the way to dedicated right away. And I’m always curious about this because everybody has a different strategy for how they configure their PHP workers. Some people use it as a selling point now to say, oh, we have unlimited PHP workers and well, that’s a lie. There’s no such thing as unlimited PHP workers. The number of workers you have is always going to be limited by the hardware you have, how many CPU cores you have because you can only queue up so many instructions before the queue starts to grow out of proportion to where you want it to be.

And then it starts to slow things down because the queue is sitting there waiting for operations. So what’s your strategy on workers? I know mine is generally three to five workers per CPU Core or VCPU depending on what you’re talking about. Because most VCPUs and cloud hosting can only really support a single thread, whereas in some environments you’re dealing with cores that can handle two to four simultaneous threads. Generally that three to five rule. The multiplier versus the number of cores you have or the number of threads you have available is my rule.

Justin: I don’t have the formula in front of me, but I can tell you that we look at a number of things. I think the PHP workers are pretty significant, especially with a site you can’t really cache. Logged in users or WooCommerce shopping experience, things like that. So we tried to basically give maybe around 60% of the server resources to the web server and PHP and then leave the rest for the database server. But you can open up the workers, but if the database obviously can’t handle it on the backend then it doesn’t really matter if you can take more web requests. So we look at those two things in conjunction. Three to four workers per CPU core sounds about in line with what we’re doing, but we’re really also looking at the database pretty closely because that tends to be where these sites get hung up anyway.

Carl: Yeah. But also you can DDoS your database and also it depends on the workload basically also, right? Because if your worker needs 50 megs of RAM to run the code, but you have another application and it needs 200 megs to run the code … Something big, then it doesn’t matter also because you could have as many workers, but your server’s going to run out of memory anyways so it’s always a calibration thing. It’s a tricky thing. People want this clean cut formula and there’s some aspects of it that’s just basically based on what you’re hosting. It changes.

Justin: I won’t say it’s a generic config. It’s obviously especially on the WordPress side, catered towards that product. But one of the things we do offer and we’re looking to automate in the near future is we actually go in and we’ll do an optimization on your site. Like a full optimization to figure out which one of your plugins is slowing you down, things like that. See if headers are configured properly and that’s something that we’ve been experimenting with offering to new customers. And the tuning of the server’s obviously important, but we’ve seen way more significant performance increases just by trying to cater to the specific website’s needs. And we’ve had sites go 30 to 40% faster just from going through that process. And then one of the other things we’re trying to do is not just optimize and then just throw them over the fence so to speak, but we want to also keep an eye on that performance and let them know if it changes. Again, I think we can continue to optimize the server stuff, but it seems like as far as impact goes, getting in there to that individual website and making those changes. And we’re taking those learnings and working to automate that, so it’s just something … It’s a button they can click in a control panel and it will actually speed up their website.

Zach: Nice. Let’s talk a little bit about where WooCommerce and WordPress in general are headed right now. The WordPress performance team has been doing some great work in trying to make performance better for all of us. And trying to optimize WordPress to perform at a higher level everywhere. In shared environments, dedicated environments, just across the board. And I don’t know how closely you’re following all of that stuff. I know I definitely have been watching what the performance team is doing to see where it all heads. Any thoughts and insights there from your standpoint?

Justin: I think one thing that can really help is some of these larger hosting companies coming together and talking about the problems that they’re seeing performance wise. We have the right connections with people on the WebPros side and we do have some people here at A2 that are invested in the WordPress side and join some of the meetings, things like that. But I think taking those shared learnings and figuring out a way to action them could be helpful. And maybe we can come up with a solution that works for everyone or at least most people. I would also like to see … And this is always a challenge, but see WooCommerce become more CDN friendly. And just think about ways they could do that. And you have very, very popular CDNs out there like Quick Cloud and CloudFlare obviously, and there might be something out there they can do together to make it more performant without having to do complete architecture overhauls in the backend.

Zach: Yeah. I think the coolest thing that I’ve seen from the standpoint of what they’re doing for performance is the performance plugin that’s introducing the new things that they’re doing before they are-

Carl: That’s WordPress. That’s not WooCommerce specific though, right?

Zach: No, it’s not. Well, WordPress performance improves WooCommerce performance. So some of the things that they’re working on though include webP support, which is cool. So uploads for webP and something in site health that lets you know if webP images are supported. That’s going to increase performance on the front end across every site just because webP is generally smaller.

Justin: That makes sense.

Carl: Yeah. What are the pain points you see or you would like to see handled?

Zach: Yeah. That’s an interesting question?

Justin: I think the front end stuff is actually less concerning with scaling because with decent CDN solutions, most of that works pretty quickly. But the WP admins experience can still be slow depending on what you’re doing, the size of your store. And so it’s interesting because our customers and customers that pay these hosting companies, their experience is on the backend. That’s what they work with. Of course they go to their own store, but majority of their time is spent on the backend. So I would personally like to see more work done, so that that can be more performant because it’s definitely a little bit harder to do because it’s again, stuff you can’t cache. If customers are experience experiencing slowness, it’s usually in WP admin and not the front end with everything else that’s going on on the front end.

Carl: Yeah. Because the application part more so than the actual content delivery part. That’s always the struggle, right? Because also it depends what they’re installing. For stores also, it varies on the type of store. What’s in the store? Even with object caching and things like that it can be really problematic and it’s hard to explain to the customers too, right?

Justin: It is. There’s a distinct difference in performance between the front end and the back end and they do notice that.

Zach: The other thing that’s interesting that they’ve done here to help with some of that is they’ve added more tests to site health, which is cool. So the performance plugin similarly to how object cache pro adds some site health checks. It has a auto loaded options health check, which is generally the place where I see databases start to fall over in the admin. It’s one of the biggest places right? Auto loaded options.

Carl: Too many of them? Just to explain it out. Just too many of them?

Zach: Yeah. Too many of them. And so there is a health check they’ve added for that. They’ve added some other health checks that are-

Carl: But that’s an interesting one because okay, you get a health check for auto loaded options, you have too many. Okay, which ones do I not auto load?

Zach: That’s the question, right? Yeah. Absolutely.

Carl: Yeah. It’s one of those tricky things where it’s like, okay, you’ve told me the thing, but if you’re not super technical, this doesn’t actually … It’s not very actionable, even if it’s a root cause.

Zach: Yeah. It’s really just nice that there’s going to be something hopefully that makes it to core here that says, hey, your site has 72,000 auto loaded options that are 7.8 megabytes in its options table, and we consider that bad. Because that might give people an indication that they should maybe do something about that. What do you do about that? Well, most of the time those things are things that plugins are adding. And if you have themes that have had their own options, that could be there too. And if they’re coded well, they’ll remove their options when you remove the plugins. If they’re not, they’ll still stick around forever.

Justin: These are some of the things our optimization team have to look at now because customers in general are not going to know which ones they need or don’t need if they’re not super familiar with how WordPress works. So that is part of what we want to automate is look for known issues that we’ve seen over and over with sites and automate that so the customers don’t have to think about that, and we just do it for them.

Zach: Yeah. It’s been cool watching the team. I hope they get to some of the more backend and admin focused things. It looks like we’re going to be getting a new admin in the next few releases of WordPress potentially, so I’ve been watching that as well.

Carl: That’s a re-skin, right?

Zach: Well, I think it’s a little more than a re-skin this time. I think they’re working on actually building in some required things for plugin authors that are going to stop some of the things like banner abuse in the WordPress admin.

Justin: That’s good to hear.

Zach: Yeah. I always love when I first log into a site when I get access to it and the things that are built into the WordPress dashboard are below the fold because there are notices from 36 plugins that all think they need to talk to a new user the second they log in.

Justin: That can be overwhelming. I’ve logged into some customer’s dashboards and they’re almost unusable because of the number of banners that were in there. Just stack them.

Zach: Yeah. And then the other stuff is more in line with bringing the rest of the WordPress admin closer to what some of the Gutenberg experience looks like now. But the stuff looks really cool. I’m excited to see where that goes. For anybody who’s interested I will make sure that Bob has a link to the initial draft of what those could look like for him to include in the show notes for this episode as well. But it’s a time of interesting changes. They’re starting phase three of Gutenberg where the focus is collaboration, which to me that’s a big scary project because if the admin’s already dated and sometimes a bit slow because of choices that people make, when we get to a point where real time collaboration is possible with multiple people connected to the same page in the admin and making edits at the same time, what does that mean for admin performance? So that’s an interesting initiative. I mean, we knew it was coming. We knew it was the goal. But to see it starting to take shape is fun.

Justin: Yeah. Immediately latency came to mind with you talking about collaborative feature. It obviously works really well on things like Google Doc and they figured that out. But I do wonder what would happen if latency was higher and you’re trying to collaborate on a post. That could get messy.

Carl: We rant about latency all the time. There’s a limit to PHP workers, but with LaMDA you can have thousands of them instantly. But latency is now an issue, right? Because even with you, you were talking about it, right? The database is on the machine. WordPress wasn’t very well architected with latency in mind. Whether it’s even the object cache latency, even something like Redis where it’s one MS or just the database being off the machines. Those are definitely scaling challenges as well. If they want it to be more of a platform for collaboration, at some point we have to start thinking about beyond one box basically and how WordPress behaves in that scenario.

Justin: Yeah. I would really like to see WordPress become more cloud aware and not single threaded like I mentioned earlier. I think that’s one of the things that makes a lot of these things a challenge. Everything’s expected to be handled in one web request.

Zach: I think as we continue to push PHP versions forward and we’ve made a lot of progress there already with just getting to where we’re requiring a seven X version of PHP now for some things. WooCommerce I believe requires seven four.

Carl: But Fiber is this 8.1 I think.

Zach: Yeah. We’re behind.

Carl: 8.1 being a minimum version for WordPress, I assume is a decade away. At least five years. And I’m being generous.

Zach: I hope not because the core team has been accelerating how quickly we adopt now. And we made a big shift from 5.6 to 7.4 in a very short period of time.

Carl: 8.2’s still pretty broken though. YMIR doesn’t support 8.2. Not because it would take me half a day to add it. It’s just there’s no point. Most of the plugins are going to break, and core has a ton of warnings.

Zach: So as we start to push further forward and we start to get to that point where we are able to do more and fix more with multithreading and everything else, as we push PHP versions, the minimum versions forward to a point where we can start to adopt some of those new features I think we’re going to start to see performance increase across the entire ecosystem. I’ve been talking about PHP seven since 2015 when I gave my first WordCamp talk talking about the Oscar Mike website and all the work we had to do to make WooCommerce performant back then and all the problems we ran into and how we fixed them. And fix is a very loose term in that case because there wasn’t much fixable in 2015 because the CRUD classes didn’t exist for taking objects out of posts and putting them somewhere else. That didn’t exist until 2017. Now we’re just seeing that stuff start to hit WooCommerce core now because plugins needed to update. And for a long time they were reluctant to force plugins to update.

Carl: Yeah. You didn’t even have the supportive PHP version flag that you could use to even do that. But yeah. I did have a talk on PHP 7 in 2016. Back then, you remember hiphop VM?

Justin: Oh man, forgot about that.

Carl: Remember when we didn’t even know whether it would be PHP 7 or it would be hiphop VM that would win?

Zach: Yeah. That HHVM created by-

Carl: Facebook. Now Meta. Yeah.

Zach: That’s actually in my presentation from WordCamp Milwaukee.

Carl: Me too. In San Diego.

Zach: Yeah. We were talking about how HHVM was actually how we made the Oscar Mike site performant because PHP 7 wasn’t out yet. And so HHVM on Mercury, on WP Engine was how we got the site running quickly. And HHVM has some restrictions that are very similar, actually, Carl, to what you’re doing with Amir in that the media library-

Carl: Yeah. If you configured it that way. You didn’t have to do it, but if you wanted to have the code cached to the max, basically it was that’s what you had to do. You couldn’t actually modify the code once it ran once. You had to restart the entire machine.

Zach: It was a get first deployment strategy. We had an offload S3 plugin that was not the more known one. It was something that we just were able to put into the repository and it worked, and we were able to do a lot of that work on HHVM. But it definitely changed the way that we had to develop and deploy. You could no longer just upload a plugin from the WordPress admin. All of these things were different. And we did all of that just to get to a point where we had acceptable performance before PHP 7 came out.

Justin: I didn’t do a whole lot with that project other than testing out some projects I was personally working on, but it definitely gave me some Perl CC vibes at first. I wasn’t sure if it was worth the trouble for our projects, but I’m curious, how long did you stay on that and was it performed enough for everything else that came along with it, all the other hoops you had to jump through? Was it worth it?

Zach: It was. The story goes that Oscar Mike had contacted me because their site had crashed on Thanksgiving. And their site crashed on Thanksgiving because the founder of Oscar Mike, Noah, a buddy of mine, had been interviewed by the voice of the Chicago Bears during the Bears-Packers game on Thanksgiving Day. And he didn’t call me before this happened. He called me when the site had already crashed. And so-

Carl: It’s such a classic sys admin story.

Zach: Absolutely. I hadn’t been involved at all with what they were doing up until that point. We had talked, I knew he was on WooCommerce. We had had conversations about what he was doing, but we had not worked together. And so he calls me. I’m at dinner with my family. And I still bring a laptop with me to family events. I have since I’ve had to start supporting e-commerce sites that could break any time, any day. And so I had my laptop with me. And during Thanksgiving dinner, I pulled it out and started trying to fix the site. And it was at some small-ish VPS host in Chicago, co-located in a data center that had nobody working on Thanksgiving.

There was no support, nobody available. And Noah’s not a technical guy, so he had never logged into the VPS. He didn’t know how to log into the VPS. He couldn’t find the password for it. It took four hours for us to get into the VPS and restart it. And then I was finally able to start looking at logs. And I was like, okay, what brought the server down? What brought it to a crawl? We got 14 orders. What brought it to a crawl? And I looked and they had email hosted on the same server. And the mail queue had run the server out of memory because of the emails that were being generated by new orders happening.

Giant, giant marketing opportunity. Bears-Packers games on Thanksgiving for those of you who aren’t from the Midwest are a big deal. It had been a classic pairing that had happened for years on end and still does occasionally. But it used to be pretty much every year. And now it’s every couple of years, every few years. But that was a huge opportunity. Tons of people watching. And that interview aired everywhere. We tried to move them from the VPS they were on to a hosting plan at Media Temple because I’d had good luck with Media Temple in the past, and they already were looking that direction. So we tried it, site crashed immediately the second we moved it. 500 errors everywhere. So I called up the folks at WP Engine who I knew pretty well. I had been talking to Steven Lynn who was running Mercury, and we decided, you know what? This might be a good candidate.

And so we signed the Mercury agreement and I started a year of my life working on site at Oscar Mike working on their website and helping to optimize their e-commerce store and their internal e-commerce operations. And that’s where a lot of the knowledge that I have around how back office systems integrate with e-commerce sites came from was being boots on the ground in an office, putting orders together and pulling things off warehouse shelves and figuring out how to organize a warehouse so it’s easier to pick, and what picking patterns happen and how to optimize that whole process as well. But that was all with Oscar Mike, and that’s how I got into this world of e-commerce was because my friend called me on Thanksgiving with a site that had crashed. And that’s how we ended up on HHVM. And the performance was definitely, absolutely worth it.

Carl: Yeah, it was good. It was good. It was good. Honestly, it was good at first because … It supported 5.6, so you didn’t have to do the PHP 7 migration to get the benefits of PHP. Because performance wise, they were roughly the same once PHP 7 came out, but you had to do the migration so the advantage of HHVM was it supported at 5.6. But the errors sucked. The errors just sucked. If you had an HHVM error, it was just obscure and it was not fun to figure out. And you also had random … It would die. It was much more like an application server. If you come from the Ruby’s and the gunicorns and the Pythons when the application server just dies, you had a lot of that. So I was not a fan basically yet. But we also moved it. We moved to that, and then I moved away. Once we migrated to seven, the code base.

Zach: So we had it configured so that it would restart every night because it couldn’t stay up for more than 24 hours.

Carl: Okay. It wasn’t that bad for me. It was not bad for me.

Zach: The server just restarted every night at two in the morning, and that’s how we kept it from running out of memory and all the other things that could happen with HHVM, we just restarted it. And the interesting thing about that Mercury project is that it was actually a collaboration between 10up and WP Engine. They had worked together to build it. And years later I ended up working at 10up for a short period of time, and it was just fun to have that story when I started.

Justin: Reminds me of the Malcolm in Middle episode where Hal fixes a light bulb and leads to the drawer being broke and everything else. That’s why I’m picturing your Thanksgiving was like that day.

Zach: It was. It absolutely was.

Carl: I don’t know about you Justin, but that’s been my life. I’ve been sys admin since I’m 16 basically. I feel like it’s always the same thing. One thing breaks and then you fix it and then something else elsewhere breaks, and then you’re stuck fixing that and then it just never ends.

Justin: I think what makes a difference in growing in that area is letting fires burn even though they’re there. You get down, you’re like, okay, I can’t touch this right now, but I’ll come back to it. Take notes, add a to do or something. But yeah.

Carl: Yeah. For sure. Yeah. Yeah. No. Definitely. You need the sprinkler system basically. Like monit or something like that. Something that monitors things and restarts things for you automatically, but alerts you know that there’s something going on but at least it’s self-contained in the sense that it doesn’t take down the whole house in the same … It’s a controlled burn, right? It’s for forest fires. You have to do sometimes controlled burns to prevent things while you control it and then you reset it and then it starts again and then you’re okay. But yeah.

Zach: So wait, is removing unneeded plugins and themes like removing brush to make sure there’s nothing for the fire to spread to?

Carl: Oh my God. I just literally had somebody in Discord … I was doing support for Amir. He like, he’s got an error. I’m like, is this a vanilla or WordPress install? He is like, yes. It’s vanilla with 250 megs of plugins. I was like, that’s not what vanilla means. I’m sorry, this is not vanilla WordPress.

Zach: So I was looking at a project the other day that has a single plugin that’s over 130 megabytes.

Carl: WooCommerce is pretty big, honestly.

Zach: Right. But this is a custom built single plugin for that site that’s over 130 megabytes.

Carl: What the hell?

Zach: Yeah. Yeah. That’s a lot.

Justin: That seems unnecessary.

Zach: Talk about building a monolith.

Carl: Yeah. Seriously.

Zach: Well that’s awesome. We’ve definitely covered the gamut as we normally do, and I want to give you both just an opportunity here as we wrap up to give your final thoughts if you have any. Sometimes I don’t, and today I don’t really. I think we’ve covered a lot.

Justin: Well, I enjoyed talking to both of you. I think the one thing I did want to mention is we’re going to be at the WordCamp in August here coming up. There’ll be about 20 of us from A2. We’ll have the entire leadership team there so we can actually talk to everybody running the different departments, plus a couple of people from pretty much every department. So we’ll be there at booth 312, I believe. So come by and visit. You’ll get to actually talk to some of the leadership team, and I think that will be pretty unique. I’m not sure if other companies are bringing their entire leadership team, but we’re also taking that time to do our quarterly planning ahead of the conference. We typically meet once per year in person, and so we figured why not make it WordCamp this year.

Carl: That’s good. That’s a good opportunity. That’s always a a good opportunity.

Zach: Yeah. Well, Carl and I will definitely be there. I know Bob is coming back to the United States for it so it’ll be fun to have some of the Do The Woo crew there as well and we’ll see what we end up doing together during WordCamp US. But we’ll all be there.

Carl: Might do some small recording.

Zach: Yeah. We’ll all be there causing trouble as we do. Right, Carl?

Carl: I’m a walking … What do you call it? Basically a walking infraction, so … Not really, but I like thinking about it that way. I like thinking there’s a wanted poster of me inside WordCamp central.

Zach: Yeah. It’s definitely there. It’s right over Cammie’s desk.

Justin: Well, it sounds like you’ll be a fun bunch there. We’ll definitely have to make some time.

Zach: Yeah. We will for sure.

Carl: Yeah. Excited to see you in person there for sure. I just do the hallway track so you’re 100% sure to see me.

Justin: Okay. Sounds good. I’ll look for you.

Zach: Yep. And apart from some meetings and lunches, because that’s what you do, I’ll be around and probably also mostly in the hallway track. But beyond that, I’m there to network and grow and that I’ve always found happens better in the hallway track.

Justin: I agree with you. It’s been a while. I haven’t traveled since 2019, I think was my last conference. It’s supposed to go to Cloud Fest in February, March of 2020, but that didn’t work out. Everything got shut down. So this will be my first conference in four or five years. Definitely looking forward to seeing new faces and old faces.

Zach: Yeah. It’ll be a good time.

Justin: Awesome.

Zach: Yeah. We will see you there. Thank you for joining us here and sharing your insights and some thoughts on this giant topic of running WooCommerce effectively. It’s always a fun one to talk about. And I look forward to having you back on at some point in the near future.

Carl: Is there anywhere somebody can find you actually?

Zach: Yeah. What’s the best place for people to reach you?

Justin: To reach me. Well, you can email me. That’s probably the best way to be honest. But JMazzi@a2hosting.com. J-M-A-Z-Z-I@a2hosting.com. Shoot me an email. My inbox is mostly under control these days, which is a good thing so I’ll see your email.

Zach: Well, we will see all of you at WordCamp USs and I don’t think we have an episode planned for next month because of WordCamp US so we may have something come out that we record there if we have the time to do so. But if not, we will see you in September.

Justin: All right. Sounds good. Well, thanks Zach and Carl. Appreciated your time.

Carl: Talk to you soon.

Zach: Thank you, Justin.