WIP: Builder Lag: Massive CPU Spikes when working with dynamic data

[pascald]

Now I am on the same page! Sure, let me do some diagnostics and send them over.

[Pixel]

I currently have 3 sites running bricks, one of them with woocommerce installed, i manage them all on Plesk, my cpu usage in the past month has been under 30%.

[r5websites]

I have had this problem for a couple weeks now on several sites I’m developing. Lag on the builder, especially on saving. Massive CPU spikes.

How can I share my credentials? Use a support ticket?

[wild]

I isolated all my plugins one by one to find out if there is any incompatibility. I noticed that the CPU spike issue only occurs when I have the WPML String Translation plugin activated.

1. When WPML String Translation is activated: When opening a complex page in Bricks, the site immediately goes offline due to high CPU usage.

I checked through htop using SSH, and the process with the highest cpu is php-fpm: pool databasename

2. When WPML String Translation is deactivated: I can open the page in Bricks without any issues.

[philipp]

@r5websites you could share your credentials via mail:

@charaf

Could you please share temporary admin access to help@bricksbuilder.io with a link to this forum thread? Also please point us to which page or template where the issue can be observed.

We received multiple access details, which were quite useful in identifying other issues (e.g. structure panel renaming lag, reordering lag, duplication lag). But now we’re trying to get more information about the server CPU usage spikes specifically. So far it seems to be related to pages with dynamic data.

@wild I dont have WPML and still got the CPU spikes. Did you share access with @charaf so that he can investigate?

[wild]

Hi guys,

I managed to solve the CPU spike issue when opening the Bricks Editor.

1. I noticed that the problem occurred only when I had {echo} tags inside an Image, Heading, etc, elements.

2. I put all my {echo} tags only in Basic Text and Code elements.

3. Example: In the image, instead of placing the {echo} tag in the URL field of the Image element, I created a Code element and placed <img src="{echo}">

4. Example 2: In the case of Headings, I created a Basic Text and placed <h1>{echo}</h1>

Based on my tests, everything is working normally. It doesn’t freeze the server when opening the Editor. Page saving is super fast too, etc.

5. I also disabled and deleted the Malcare plugin (Cloudways) because it was causing conflicts. But that wasn’t the main solution.

[wild]

Yeah. I tested in live and it worked

Note: My issue wasn’t lag in the interface, but CPU spikes and the site going down immediately after opening a complex page in Bricks Editor.

[philipp]

Thats interesting, maybe this insight will help @charaf in his investigation.

@wild: So from now on, you are only using baisc text and code elements?
No more Image, Heading, Richtext, Text Link etc?

This is not a solution a lot of professionals can work with - there needs to be a fix by Bricks.
We need Image, Heading, Richtext, Text Link etc.

[charaf]

Hi @philipp,

@wild’s issue sounds totally different than the one you’re having and that we’re discussing on this forum thread (CPU spikes on page load in the builder when “Render dynamic data text on canvas” is enabled). @r5websites’s however might be similar and we’re in touch with him through email.

[wild]

@philipp In fact, I can use all the elements normally, but not in combination with the {echo:} tag.

If I intend to create a regular image element, no issues. But if I want to use an image element where the image link is through a {echo:} tag, then the solution I found is to insert this image through the Code element.

This isn’t the ideal solution, but it’s the way I found to resolve it until it’s fixed. (I don’t know if it’s a problem with my host Cloudways or with Bricks)

[charaf]

Could you please create a separate report for this or share replicable steps to help@bricksbuilder.io.

The issue you’re describing is different from the topic of this thread, but if it’s replicable we’d like to take a look at that too. Please also share the function being called using the echo tag when you create a separate report.

[ChrisBeattie]

I have also experienced this. It only seems to happen when using dynamic data within query loops.

[charaf]

Do you get server CPU spikes on page load in the builder? If so:

@charaf

Could you please share temporary admin access to help@bricksbuilder.io with a link to this forum thread? Also please point us to which page or template where the issue can be observed.

Also please include your hosting provider & server specs.

[ChrisBeattie]

Sorry @charaf, this project has been sent to the client, and I no longer have access as it was a build only task.

The issue always happened when editing a page with dynamic data within query loops. I would get massive CPU spikes and my whole hosting would go down and all sites on that server would show a 503 error.

I don’t remember any reason it would happen, as it would be sporadic. Sometimes it would happen after the builder had loaded and the page was compiling, other times just randomly when building the page.

I never really experienced slow speeds when saving or building like other areas saying.

The server is with Hostinger:

250 GB NVMe Storage
6 GB RAM
4 CPU Cores

If I experience this again I’ll get access over to you.

[ChrisBeattie]

@charaf Sorry another important thing I forgot to mention, the queries on the page were for The Events Calendar events post type. I was querying dynamic data from TEC and ACF linked to the events post type in some of the loops.

For example the same loop would include:

{featured_image}
{post_title}
{echo:tribe_get_start_date( {post_id} )}
{acf_custom_example}

It could have more too.

[secondwho]

@charaf

I have encountered the same error, which also occurs only on pages with dynamic data and additionally in the attributes. Whenever there’s an incorrect input, for example, text in combination with dynamic content, the page goes offline, and the server becomes unreachable.

[dimitrikhoury]

Hello @charaf,

I have a website that is experiencing massive CPU spikes. Almost every time I open a template, it either errors out and gives me a 504 error or logs me out (I have never seen that before). I have WooCommerce installed, and it’s a pretty complex website with multiple CPTs.

It’s on a decently sized VPS, and it’s just this website and the staging website on it. The specs are:

The server is from Digital Ocean
2 vCPUs
4 GB of Memory
50 GB of SSD

I’ll email you the credentials and a URL.

[charaf]

Hi @secondwho,

Welcome to the forum!

I’m unable to replicate the attributes issue locally. Could you please create a separate thread with more details (e.g. a screen recording) as it seems to be a separate issue?

---

@dimitrikhoury thank you for sharing access, I will be checking it out and get in touch with you over email.

[danieliser]

@charaf Fellow plugin dev here so I’m happy to dig into this if needed, but It took a while to try and track this down, still not quite sure I understand the extent of what is happening, but I have narrowed it for all purposes to dynamic data renders.

In the attached videos/screenshots you can see it happen.

1. Created a counter element.
2. Added non dynamic data, you can see it call the REST API for render_element I believe, near instant.
3. Paste a dynamic data echo function that simply returns a static integer as the start or end value for the counter.

I immediately see dozen + AJAX requests, clicking through appears its triggering a resave on nearly ever element to the root, maybe sibling trees too, not sure.

4. If you then try to edit said {echo:} function calls, it starts making the same dozens of AJAX requests for every keystroke or 2 (live rendering I assume).

5. Once dynamic props are on the element, you can modify any field not containing dynamic props and the issue doesn’t occur. If you start typing in a field with dynamic values though it goes nuts.

This quickly stacks up hundreds of requests, bringing even an extremely over powered server to a crawl as each of them slowly finishes or 504 timeouts.

First image is showing that it not only maxed out one node, but 3 nodes. Each node is 10 CPU cores (XEON Gold) and 10GB memory, x3.

You can see the entire process recorded in chrome dev tools network tab. Cut the video as it was several minutes to finish all of them successfully. You can see how this would be painful editing experience, as the editor is nearly useless at the time these requests are processing.

Screen Recording 2024 05 30 at 1 19 47 AM

Screen Recording 2024 05 30 at 1 23 18 AM

---

Here would be my recommendations based on SAAS & WP experience:

1. Set up your ajax calls to be cancellable.

• On client side, every request should be stored and abortable. This should be be used in a few ways:
• On server side, either ensure your disabling ignore_user_abort during your requests, or explicitly use methods to check if the connection is still active during your processes, bailing as soon as you detect its not, do so with things like connection_aborted() or even connection_status() != CONNECTION_NORMAL.

2. Any time an element is saved, the requests object should be stored in a keyed object/cache, but before any save, you first check if there was a previous request object in the cache for that element, and if its still running, abort it before making another.

3. Any time an element is moved or deleted, cancel pending requests for that element etc.

4. Any time the browsers stop button is clicked, or esc pressed when no element is selected, all pending should abort.

5. Add a debounce or throttle to your AJAX saves in general.

This is how major SAAS systems handle forms such as Remix.run: Network Concurrency Management | Remix

while (TRUE) {
  if(connection_aborted()) {
      break;
  }
  sleep(5);
}

var xhr = $.ajax({
    type: "POST",
    url: "some.php",
    data: "name=John&location=Boston",
    success: function(msg){
       alert( "Data Saved: " + msg );
    }
});

//kill the request
xhr.abort()

Overall we love Bricks, we have pages that not only look great but take less than 50-100kb to load, but the broken ajax in the editor for several versions now has made this an unbearable experience most times.

Please let me know what other useful info might help solve this once and for all, but I think the above are sound solutions either way for ongoing performance improvements.

Reach out to me directly, twitter, email, Post Status slack, here IDC, lets fix this.

[philipp]

Wow, this sounds like you found something that the CPU Spikes could be pinpointed to!
Thanks for your valuable report, I hope this helps @charaf for the investigation.

What supports your finding: My hosting provider told me, there are lots of admin-ajax requests when the CPU Spikes happen. They are not sure why Bricks Builder does this.