Out of Memory – Scalability issue with “Blog Posts” element and a render loop

Hey there,

we just came across one of those nasty scaling issues on a clients site of ours.

They run Enfold with nearly 1k posts (real post_type=”post”) besides even more pages and other CPTs.
Yesterday they hit “a wall” causing reproducible OOMs on their posts in the editor as well as on the Frontend and other parts of the website.

Some context information (although mostly irrelevant):
PHP 8.1
Enfold 6.0.6
WP 6.7.1
Max Mem: 512M
Avg Max Mem Consumption on Posts in Frontend and Backend: ~80M

We dug deep and ran APM Traces on the problematic posts. We figured out that a combination of the following UI Builder Element(s) and Post Config is a guarantee to hit the OOM at some point in time:

– Create a Post and add it to Category “A”
– Add the following ALB Element(s) to the Post:
— “Blog Posts” with “Show Blog Posts” and select Category “A” to display (<– The clients have this configured to be recursive as the same post will be displayed in the list itself – don’t think they did this intentionally they just did not set an offset)
— “Entry Slider” with some other Category than “A”
– Create many of these Posts

For reasons we have not analyzed in the Enfold code yet the APM clearly showed a loop triggered between “do_shortcode” and “load_template”. With many occurences in “locate_template”, “get_template_part”, “avia_sc_blog::shortcode_handler” and “aviaShortcodeTemplate::shortcode_handler_prepare”.

As the whole OOM is gone when the “Show Blog Posts” element is removed from the Post we assume that the Blog Post Element kind of itself “renders” the content of all of it’s displayed blog posts, leading to a rendering of all of the selected blog Posts of the Blog Posts element on that page, leading to a rendering of all of the selected blog Posts of this element…… [-loop-].

The issue is so wide spreading that all of the posts being using this Element with the Category “A” are OOM. Some other functions of the site were OOM as well but we did not analyzed deeper as these errors were gone as soon as we solved the issue with the Post. I assume they might have some relationship to one of the “OOM posts”.
To fix the wide spread OOM we simply needed to move the latest post to the trash. Restoring it lead to OOM at all effected posts again. Or removing the Blog Posts Element.
Increasing the memory of the site did not help at all. Within the WordPress backend editor there is no obvious high memory consumption when analyzing with Query Monitor for example.

The findings clearly indicate that there is a loop that needs to be stopped at some point.
Hope you can assist and find way to allow our clients to continue using the elements with referencing their posts internally.
If you believe this can be solved by a configuration change in one of the UIB Elements, let me know. But I fear they will not be happy if they have to change several hundreds of posts ;-).

Thank you very much and best regards,

Jan