I thought i’d ask here incase anyone has overcome a similar issue.
For background we started development of this site over a year ago, and it has 52 language variants.
We have some doctypes were all the properties vary by culture, and some where all are shared but our blocks within blockbuilders vary by culture (as you can do in 15+).
For reference we are tied to v15 until launch for various reasons.
We have found, when unpublishing doctypes where:
There is a large amount of block builder content
The doctype and the blocks property are both vary by culture
That unpublish operations are VERY expensive.
For example, unpublishing a node in all languages, on an Azure SQL database with 100 DTU’s, will take around 5 minutes and completely max out the database.
Conversely, publishing the same node to all languages, although slow, is still within tolerable bounds.
Unpublishing nodes where properties are set to shared completes within seconds.
One thing i notice is that publishes create 1 audit in the form. “Document published to : en-US,en-GB etc..”
Whereas unpublish, each language variant has its own audit entry.
Is there any known workaround to improve unpublish times? At the moment, it’s not really suitable for production.
The CMS has a focus on performance improvements, generally from 16.4+, and more is to come.
In that aspect, I would highly recommend you to upgrade to the latest (17.1), which comes with various improvements that would improve your case.
I did read that you are tied to v15, but I would really recommend investigating/challenging why that is.
V.16 and v.17 are improvements of v.15, there are no notable breaking changes, only one being that TinyMCE is no longer in Core from v.16. But since you are running v.15, I hope you would be using TipTap already. Otherwise, you can continue to use TinyMCE via the community package.
I also want to highlight that v.16 and v.17 is mainly polishes & bugfixes of v.15. So I would not view v.16 & v.17 as major versions in that regards, there are some technical breaking changes, but I would not think it would have any negative impact on your project.
And once you get there, please continue to upgrade, all minor versions of v.17 are bringing a more solid and faster CMS to you.
Just to also note that v15 is already end of life and any support you might get now would be workarounds and hacks that definitely need to be undone again before going to v17 (or above).
Just mentioning it as I would wish for you to be careful out there!
The one thing I will encourage you to do is to set up the same Azure environment with a backup of your current database, but running on v17. Test the same unpublish and see if that makes a difference. If it doesn’t make a difference then more performance improvements in the CMS might be needed.
Thanks, I appreciate your responses and this seems helpful.
Not tied to 15 forever, just we wrote a very involved custom AI translation manager setup that is tied to existing BlockList json structure, any change to this would break this functionality, but this is a development tool not required after launch.
Testing out v17 for performance improvements is in my task list already - I will let you know how it goes!
