I always use SPList.GetItems(SPQuery). According to this URL http://msdn.microsoft.com/en-us/library/bb687949.aspx#WorkingWithFoldersLists

I know PortalSiteMapProvider provides an automatic caching infrastructure for retrieving list data. The GetCachedListItemsByQuery method of PortalSiteMapProvider takes an SPQuery object as a parameter, and then checks its cache to determine whether the items already exist. If they do, the method returns the cached results. If not, it queries the list and stores the results in a cache. This approach works especially well when you are retrieving list data that does not change significantly over time.

The list in question has more than 40k items that will not change. If I only need one item from this list at any given time, do I use SPList.GetItems or PortalSiteMapProvider.GetCachedListItemsByQuery?

My SPQuery object

SPQuery objQuery = new SPQuery();
objQuery.Query = string.Format("<Where><Eq><FieldRef Name='Title' /><Value Type='Text'>{0}</Value></Eq></Where>", entry);
objQuery.RowLimit = 1;

Is it okay to use GetCachedListItemsByQuery if the value in the where clause is different everytime?


The PortalSiteMapProvider class was one of the best performing data access methods in every scenario. However, there are a couple of limitations in using it. First, because of the way in which the data is cached, use of the PortalSiteMapProvider class is going to be most useful if the data you are retrieving is not significantly different over time. If you are trying to frequently retrieve different data sets, the PortalSiteMapProvider class will incur the overhead of constantly reading from the database, inserting data into the cache and then returning it from the method call. Clearly, the advantage of the PortalSiteMapProvider class is when it can read data directly from the cache.



In one case the use of SPList.GetItems(SPQuery), which is good, still lead to frequent server break-downs. The database server was getting to much load. Replacing it with PortalSiteMapProvider.GetCachedListItemsByQuery(PortalWebSiteMapNode, string, SPQuery, SPWeb) in the hot spots of the calling code took a lot of pressure from the database server. In another example we could improve the average page rendering from 8s to 2s by using the PortalSiteMapProvider.GetCachedListItemsByQuery(PortalWebSiteMapNode, string, SPQuery, SPWeb) and replacing SPListItemCollection.GetItemById with SPList.GetItemById.

Because the PortalSiteMapProvider.GetCachedListItemsByQuery uses the object cache you want to make sure that it works efficiently. This is not a trivial task. You can find more information here. The bottom line is that you should monitor the ‘SharePoint Publishing Cache’ performance counter on the production server. The number of ‘Total number of cache compactions’ should be 0 to 1 within an hour.



yes GetCachedListItemsByQuery is fine aslong as the data doesnt keep on getting changed all the time ;) which i think you said stays the same :), either method is fine to use but as its already stored in cache why not use that option as its less expensive on the server :)

hope it helps :)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.