BRXM 14.5.0 performance issue

1

Hi all,

we are running 14.5.0 version of bloomreach which is hosted in our gke cluster. We have around 20K records in our cms and we have mounted the disk volume to cms storage which means cms contents are being written/read to/from the disk. Now we are experiencing much slowness while using cms console. Even we tried to expand article node it got hang for sometime. We have grafana and other dashboards setup which suggests that our CPU and Memory consumption is below the limit (CPU limit is 8 core, Memory is 12 GB) which rules out the issue of high CPU and memory usage. Please suggests what could be the reason for this slowness. We are suspecting that cms is taking good time in reading/writing to disk when the cms already have more than 10K contents. But we are not very sure on this and even if this is the issue then how can it be optimized. Please guide on the same .

@machak @jasper.floor if you can help me would be apprectiated for this!!.

Thanks,

2

HI,

this is a bit of a complex issue for the forum. Possible reasons could include, number of sibiling nodes (try not to have more than 100 siblings), size of version history, size of event log, and probably others I haven’t thought of. First I would do some clean up:

Then check your node structure for excessive siblings.

If these are not the case I encourage you to reach out for support from our services department.

3

Thanks @jasper.floor for your reply,

Just want to confirm one thing. You mentioned the term ‘sibling node’ by which I believe you are referring to the nodes created in any content (article/page) which in turn refers to the size of any content. Also when you say ‘100 sibling nodes’ does it mean that the level of the nodes within a single content should not exceed 100 or does it mean one translated folder should not contain more than 100 items/contents… Please confirm the understanding.

Thanks,
Manish Kumar

4

I mean nodes on a jcr level. In terms of content, folders and documents are nodes. Within documents, compounds are nodes. Compounds within other compounds are also nodes. So no more than 100 compounds in a document, or 100 compounds in a compound, though both scenarios are unlikely. 100 documents in a folder is much more likely and should be restructured. You can have any depth, so 100 nodes that are a line children are not a problem, only siblings. This is a limitation of the underlying technology and not something we are able to correct.

1 Like
5

Thanks @jasper.floor for your response, working on your suggestion.