I have a client site which makes pretty extensive use of the MNTP however as a result it has major performance problems, something I've touched on in another thread and which Shannon has indicated there are known performance issues with MNTP.
My question is, are there any active developments going on to address this with MNTP and is there anything I can do on a v4.11.8 site in the meantime? One of the doctypes has about 6 MNTP's on it and I accept that this page might be slower to load but it's a homepage and I am sure they can live with it but other nodes only have 2 on them and suffer very similarly in terms of the performance hit.
I should probably add, in relations to Shannons comment in the other thread that nodes with no MNTP load lightning fast!
Thanks to a good spot from Tom Fulton I managed to identify the source of the issue while at CodeGarden 13 and it was not MNTP related at all but to do with a pretty complex (for me anyway) XPath query which once removed and replaced with a usercontrol to achieve the same result brought Umbraco back to life and removed the huge performance hit on each node in the back office.
For those that might be interested the query was as follows:
descendant::*[@isDoc and @id = $ancestorOrSelf/ancestor-or-self::*[@isDoc and sidebarPanels/*/nodeId][1]/sidebarPanels/*/nodeId]
To give credit where it is due, the above creation was thanks to Lee Kelleher's help which helped me get a project out of the door. Performance issues aside it is a crazy bit of code which revisting now I am still trying to get my head around how it works.
Thanks for returning with info for anyone who'd stumple upon a similar issue!
As far as XPath goes, it's worth repeating for anyone dropping by, that using the descendant(-or-self):: and ancestor(-or-self):: axes are good pointers that there'll be some busy travelling up and down the tree - which slows down as the overall number of nodes in the solution increase.
- As for the query - it looks for any descendant which is has been selected in an MNTP property (sidebarPanels) on either the current node or an ancestor thereof - right? Only real optimization of that would be to include the Document Type aliases involved instead of the star-selectors - but that would only help if looking for a specific Document Type and there were many different types involved...
The use case was that all sidebar panels are inherited on child nodes however they wanted the ability to exclude specific inherited sidebar panels on certain nodes without breaking the inheritance further down the tree. The property is on every node so restricting to certain doctypes is not an option. On this occassion going back to my roots (c#) was more performant on this occasion I'm afraid. The XPath query was causing up to 40 second delays when navigating between nodes in the back office.
Multi-Node Tree Picker (MNTP) Performance Issues
I have a client site which makes pretty extensive use of the MNTP however as a result it has major performance problems, something I've touched on in another thread and which Shannon has indicated there are known performance issues with MNTP.
My question is, are there any active developments going on to address this with MNTP and is there anything I can do on a v4.11.8 site in the meantime? One of the doctypes has about 6 MNTP's on it and I accept that this page might be slower to load but it's a homepage and I am sure they can live with it but other nodes only have 2 on them and suffer very similarly in terms of the performance hit.
I should probably add, in relations to Shannons comment in the other thread that nodes with no MNTP load lightning fast!
Cheers, Simon
Thanks to a good spot from Tom Fulton I managed to identify the source of the issue while at CodeGarden 13 and it was not MNTP related at all but to do with a pretty complex (for me anyway) XPath query which once removed and replaced with a usercontrol to achieve the same result brought Umbraco back to life and removed the huge performance hit on each node in the back office.
For those that might be interested the query was as follows:
To give credit where it is due, the above creation was thanks to Lee Kelleher's help which helped me get a project out of the door. Performance issues aside it is a crazy bit of code which revisting now I am still trying to get my head around how it works.
Hi Simon,
Thanks for returning with info for anyone who'd stumple upon a similar issue!
As far as XPath goes, it's worth repeating for anyone dropping by, that using the descendant(-or-self):: and ancestor(-or-self):: axes are good pointers that there'll be some busy travelling up and down the tree - which slows down as the overall number of nodes in the solution increase.
- As for the query - it looks for any descendant which is has been selected in an MNTP property (sidebarPanels) on either the current node or an ancestor thereof - right? Only real optimization of that would be to include the Document Type aliases involved instead of the star-selectors - but that would only help if looking for a specific Document Type and there were many different types involved...
/Chriztian
Hi Chriztian.
The use case was that all sidebar panels are inherited on child nodes however they wanted the ability to exclude specific inherited sidebar panels on certain nodes without breaking the inheritance further down the tree. The property is on every node so restricting to certain doctypes is not an option. On this occassion going back to my roots (c#) was more performant on this occasion I'm afraid. The XPath query was causing up to 40 second delays when navigating between nodes in the back office.
Cheers, Simon
is working on a reply...