Pro Theme and WPMU issues (major performance leak)

[magikweb]

Hello,
Does anyone use WPMU with Pro?

We have a bug that’s been crashing our server for quite a while now.
Reference: https://theme.co/apex/forum/t/follow-up-for-wpmu-fix-temporary-or-not/47724

We’d like to know if anyone were able to solve this. If not, if anyone would like to give it a try or point our devs in the right direction. We can apply a patch, but we don’t know the framework (ember?) used to build Pro.

PS: This issue does not happen on regular WordPress, only WordPress with Multisite enabled.
Thanks everyone!

[michaelbourne]

Just thinking out loud, but the effect of this issue would be no different than having bursts of uncached traffic hit the server (like a Woocommerce site getting bursts of people trying to add to cart or checkout at the same time). Essentially the preview window fires admin-ajax, reloading the site each time.

If that’s enough to crash a server, I’d say the site itself needs some tune up. How much data is processed on every admin page load? How many queries? How much autoload data is in the database?

Obliviously no replacement for being able to control the refresh interval in the builder, but it can help improve what you’re seeing.

I run ecommerce sites that see hundreds of users checking out at once and the servers don’t crash, so it is possible. What’s your setup look like?

[magikweb]

Hello Michael,
That’s a good point and we don’t fully understand why it takes so much ressources.
It’s a VPS with 4 cores and 8GBs of RAM at SiteGround, it technically can handle much more than 50 requests.

30 fast queries, no problem, +10-20% ressources usage for a second.
60 fast queries, lockdown, 100% of CPU and RAM.

It’s like there’s a loop/conflict within WP or the host triggers some DDoS protection (still would be excessive).

We did contact them, but it was not conclusive. We’ll contact them again with a step-by-step to reproduce the issue, worst case they can’t help, but it’s worth a try.

On a different angle, we tried capturing the JS event so we could manage it, but we have no idea which frame fires the event.

Thanks for the follow-up, out loud thoughts are appreciated.

[michaelbourne]

If you have the time and resources, I’d even suggest a couple hours testing the same setup on a different host.

You can get the same server specs on Cloudways.com for half the monthly cost (or a 16Gb, 6 Core VPS for less than you pay) with Vultr.

Cloudways is hourly billing. Set up a new account, use the coupon code XPROS for a $30 credit when you add billing information. That will basically buy you a few days for free on a better server to run the test.

Add the new server, tweak the server setting (like PHP version, mariadb, memory limits, etc)

Then clone the multisite over, and see if you get the same results.

At the very least, you will walk away with an answer of whether or not your current setup is a weak point in your system, which could make it easier to choose how you proceed.

[magikweb]

Your test is a good idea. Before reading your post, we setup a separate VPS (SiteGround) with a naked WPMU + Pro. The problem persists and crashes that VPS as well.

After inspecting it, the raw AJAX query that CornerStone sends is somehwat heavy and does take a lot of processing / CPU. It’s definitely not made to be triggered multiple times in a row.

Nonetheless, your test could be very conclusive and a strong argument when suggesting the issue to SiteGround.

Before finding a different host for test purposes, we’ll test a “GoGeek” hosting (we have many anyway). We think the Cloud setup has an odd quota management.

While this is a very important element to validate (server performance), I hope that Themeco will either fix this or tell us which file triggers the call so we can patch it.

[michaelbourne]

Let us know how it goes!