Fetch multiple nodes, very slow or poor performance,Member.GetAllAsList()
Hi!
Been playing around with the Members-api.. and more especially the Members.GetAllAsList()-method.. and it seems like that part of the API is extremely slow.. is there any other better way to boost the performance?..
Also seems like fetching multiple IContents takes quite some time.. cant remember the exact scenario right now, but will get back to you once I have some more information to share.. guess how ever that the general idea when it comes to "filtered-nodes" is to always query the nodes with XPath to only retrieve the nodes I actually need? Fetching all and then do some Linq-magic seems to be quite a performance loss... am I correct?
I think it's fair to say that the member GetAllAsList() and Member.GetAll should be avoided when working with a certain number of members.
What I tend to do for querying members is making use of Examine. I then startby adding my properties to a new member index and go from there :-) Using the fluent examine query language is quite easy.
As for content. Using IContent (and contentservice) makes you hit the database which is not ideal when we have access to the in-memory XML cache. I think IPublishedContent should be used instead. When you have an IPublishedContent object, you should be able to parse the content tree, something like this:
IPublishedContent myNode = Umbraco.TypedContent(1234); var childNodes = myNode.Children;
I get the idea of both the solutions.. how ever I find it very strange that we have to use examine to do such a simple task.. and what if I actually want all members?.. would I query examine with out any criteria?.. seems like a huge miss in the database-design.
Regarding querying a tree of IPublishedContents.. what if your actually want to do this outside of the razor-view.. would UmbracoContext.Current.Services.CacheService.GetById do it?
And same goes for that one.. what if I dont want to fetch the data from the cache for some reason but still need the performance to be "topnotch"?
Is the database-querying performance an issue caused by bad database-design or un-optimized queries?.. anybody that happens to have some further insight :)?
If you use the Umbraco Member API it will do a lot of db calls. That's because the Member API is like the old Document and Media API. They are to update content and not for just reading. Currently the Member API will be updated for 6.2.0 (http://issues.umbraco.org/issue/U4-1659), but if you want to work with a lot of members it's better to try uMembership. It has much better performance.
Fetch multiple nodes, very slow or poor performance,Member.GetAllAsList()
Hi! Been playing around with the Members-api.. and more especially the Members.GetAllAsList()-method.. and it seems like that part of the API is extremely slow.. is there any other better way to boost the performance?.. Also seems like fetching multiple IContents takes quite some time.. cant remember the exact scenario right now, but will get back to you once I have some more information to share.. guess how ever that the general idea when it comes to "filtered-nodes" is to always query the nodes with XPath to only retrieve the nodes I actually need? Fetching all and then do some Linq-magic seems to be quite a performance loss... am I correct?
Hi Inx51,
I think it's fair to say that the member GetAllAsList() and Member.GetAll should be avoided when working with a certain number of members.
What I tend to do for querying members is making use of Examine. I then startby adding my properties to a new member index and go from there :-) Using the fluent examine query language is quite easy.
As for content. Using IContent (and contentservice) makes you hit the database which is not ideal when we have access to the in-memory XML cache. I think IPublishedContent should be used instead. When you have an IPublishedContent object, you should be able to parse the content tree, something like this:
For a complete overview of methods for querying from an IPublishedContent, check this out: http://our.umbraco.org/documentation/Reference/Mvc/querying
Hope this sheds some light on it :-) If not, please let me know.
All the best,
Bo
I get the idea of both the solutions.. how ever I find it very strange that we have to use examine to do such a simple task.. and what if I actually want all members?.. would I query examine with out any criteria?.. seems like a huge miss in the database-design.
Regarding querying a tree of IPublishedContents.. what if your actually want to do this outside of the razor-view.. would UmbracoContext.Current.Services.CacheService.GetById do it?
And same goes for that one.. what if I dont want to fetch the data from the cache for some reason but still need the performance to be "topnotch"?
Is the database-querying performance an issue caused by bad database-design or un-optimized queries?.. anybody that happens to have some further insight :)?
Hello,
If you use the Umbraco Member API it will do a lot of db calls. That's because the Member API is like the old Document and Media API. They are to update content and not for just reading. Currently the Member API will be updated for 6.2.0 (http://issues.umbraco.org/issue/U4-1659), but if you want to work with a lot of members it's better to try uMembership. It has much better performance.
Jeroen
Ok thank you :) I will try that.. is there any alternative for Umbraco 7.0?.. or is the member api already improved in that version?
7.0 is already out and doesn't have the new api yet. 6.2.0 will come out soon with the new API and will then be ported to Umbraco 7.
Jeroen
is working on a reply...