Heavy performance degradation with deeply nested components in a dynamic zone

[Xzandro]

Bug report

Required System information

• Node.js version: v18.13.0
• Strapi version: 4.6.0
• Database: PostgreSQL 14
• Operating system: Ubuntu 20.04

Describe the bug

To preface, I'm not quite sure if this is considered a bug, but I will try my best to explain it. First of I know, that it is not advised to nest components more than 2 levels deep, but frankly, for a real website, you really kind of have to, to give the client at least a decent way to manage the content. This could be also incredibly important in case features like dynamic zones in components will be implemented, which they definitely should in my opinion.

In my case I have deeply nested components, up to 7 levels deep. I basically have a dynamic zone and from there I let the client add components, which I then render via nuxt.js on the frontend. I will add a gif to show the "worst" case scenario, since it does not fit in a screenshot. Obiously in some cases multiple of these components can be on the site.

Issue is, that if all levels are populated, the Saving process gets extremely slow. I suspect, that it is because of the sheer amount of queries, that are partly dependent on each other, are executed. This in itself would not be bad, but if the database is not on the same host, with slight latency involved, it can be extremely slow. On the same network, this request will take 3 seconds, on my DigitalOcean App Platform + Managed PostgreSQL databse (production), it will take 10 seconds and if I connect to a remote database locally (I know, this definitely should never be done) from my PC, it will take 60+ seconds to finish. This also affects GET requests, (I use the populate-deep plugin) but it is definitely not that bad (mostly 1500ms-2000ms for the site with most of the content) and can be improved by cache, which I already use. I will attach another gif of the queries being executed just for this single saving request.

Keep in mind, I'm certainly no expert in this, but after I noticed the performance differences I at first suspected CPU or memory, but that does not seem to be the case - according to their insights section, they are basically bored.
I'm also not quite sure what the solution to this really is. Maybe only save the content that was actually changed (if not already the case)? Or some other way to reduce the queries needed.

Ultimately, I do not even think that these use cases are completely outrageous if you would like to give a client lots of options and I definitely want to spread awareness of this potential issue.
Or maybe I did something wrong myself - in that case please tell me how to relieve this situation a little bit.

Steps to reproduce the behavior

1. Create a dynamic zone with deeply nested components
2. Populate components with data
3. Save the content type
4. See how slow it saves depending on the environment

Expected behavior

Improved performance in general for deeply nested components / relations

Let me know if you need more information or anything else.

[petersg83]

Hello @Xzandro! Thank you for reporting the issue. It's something we were wondering: if that would happen for some users. In the last release a fix was done to avoid deadlocks : #15535 The fix logic is to replace parallel requests with sequential requests. It does slow down the saving request but we thought it would be still ok. Your report shows that it's not invisible for some usecases.
We consider that having that many nested components is an edge case and a situation we try to discourage (in the Content-Type Builder it's not allowed to have more than 2 levels of components).
Having said that we still try to cover this usage as much as possible.
Deadlocks only happen on MySQL and MariaDB, so we can change the code so it behaves differently for Postgres. That should fix the issue for you (but not for everyone)

[Xzandro]

After looking more into this. Yes, its much better in versions before 4.6.0. The case for me via a remote database is 26 seconds with 4.6.0 vs. 4.5 seconds in 4.5.2. I wouldn't call it particlarly fast, but yea, it is an improvement.

I'm a bit worried, that these situations are called edge cases, because I would highly disagree with that. For me, that looks like a totally normal website structure you would find in any other CMS like Wordpress, typo3 or Contao. Does this mean, that these cases will never be further improved at all? If that is the case, I do not know if I could ever recommend Strapi for normal customizable websites, where you want to leave the client with lots of options, so you do not need to cover every new case. My content team was also surprised that these are called edge cases.

Thank you for the quick response though and I am excited for an update for this issue.

[Marc-Roig]

@Xzandro We are working on this right now :) We should provide a solution for this issue in 4.6.1 ( for databases that are not mysql though).

Probably "edge case" is not the best wording for this. What we refer by edge case is normally a functionality that is not used by the majority of the user base, but we do prioritize it.

This use cases are the ones used by people who deeply uses and understands Strapi a lot. So being an "edge case" doesn't mean we won't fix it. Still, we try to discourage the use of deep nested components yet not only because of potential performance issues but UX issues too.

There are things we have to improve in Strapi to provide a quality solution for that use case :)

Saying that, I will come back when the fix is ready 🚀 Thank you for providing the issue description.

BTW, what are you using to display the query statistics?

[derrickmehaffy]

Upgraded sev due to EE customer that will have this issue in the near future when they want to upgrade.

[Xzandro]

@Xzandro We are working on this right now :) We should provide a solution for this issue in 4.6.1 ( for databases that are not mysql though).

Probably "edge case" is not the best wording for this. What we refer by edge case is normally a functionality that is not used by the majority of the user base, but we do prioritize it.

This use cases are the ones used by people who deeply uses and understands Strapi a lot. So being an "edge case" doesn't mean we won't fix it. Still, we try to discourage the use of deep nested components yet not only because of potential performance issues but UX issues too.

There are things we have to improve in Strapi to provide a quality solution for that use case :)

Saying that, I will come back when the fix is ready 🚀 Thank you for providing the issue description.

I appreciate this quick improvement to the situation. This also makes me excited for the future of Strapi in general, that these cases are in fact acknowledged and somewhat supported. Ideally we have these cases further improved UI and performance-wise as well, so we do not have the hassle to manually edit schema files for example.

BTW, what are you using to display the query statistics?

This is provided by the managed database UI from DigitalOcean by default. Comes in quite handy in some situations. :)

[derrickmehaffy]

@Xzandro We are working on this right now :) We should provide a solution for this issue in 4.6.1 ( for databases that are not mysql though).
Probably "edge case" is not the best wording for this. What we refer by edge case is normally a functionality that is not used by the majority of the user base, but we do prioritize it.
This use cases are the ones used by people who deeply uses and understands Strapi a lot. So being an "edge case" doesn't mean we won't fix it. Still, we try to discourage the use of deep nested components yet not only because of potential performance issues but UX issues too.
There are things we have to improve in Strapi to provide a quality solution for that use case :)
Saying that, I will come back when the fix is ready rocket Thank you for providing the issue description.

I appreciate this quick improvement to the situation. This also makes me excited for the future of Strapi in general, that these cases are in fact acknowledged and somewhat supported. Ideally we have these cases further improved UI and performance-wise as well, so we do not have the hassle to manually edit schema files for example.

BTW, what are you using to display the query statistics?

This is provided by the managed database UI from DigitalOcean by default. Comes in quite handy in some situations. :)

We certainly can't promise a fix as it's quite likely to make the required improvements would mean breaking changes so it may have to wait for Strapi v5 but we are certainly trying our best.

[Xzandro]

That is understandable. I think we can live with this state for now after the fix is applied for PostgreSQL at least to resolve the regression. My best outcome would be that this remains on the radar though, so that in the future these kind of structues have better support to close the gap between Strapi and existing other common CMS.