Scaling to Extremely Large Lists and Performant Access Methods

re: Scaling to Extremely Large Lists and Performant Access Methods

Martin Edelius — Wed, 25 Jul 2007 15:56:39 GMT

Thanks for the info.

I'm guessing this applies to WSS as well?

re: Scaling to Extremely Large Lists and Performant Access Methods

Martin Edelius — Wed, 25 Jul 2007 16:44:02 GMT

Doh - I just read the summary so I didn't see that this *does* indeed apply to WSS as well.

So, if my first comment gets approved - disregard it. ;)

re: Scaling to Extremely Large Lists and Performant Access Methods

cquick — Wed, 25 Jul 2007 17:45:37 GMT

This is good information to have. However, I have a list containing around 3,500 contacts. When I attempt to use this list in conjunction with Microsoft Access, I get error messages. Could this be due to the constraint (or recommendation) of 2,000 items?

re: Scaling to Extremely Large Lists and Performant Access Methods

Peter {faa780ce-0f0a-4c28-81d2-3667b71287fd} — Wed, 25 Jul 2007 18:07:56 GMT

I just read the document, and I'm shocked: 50 seconds to delete a single item from a large list! Wow. Thanks for the honesty, though :)

* NOW AVAILABLE * White Paper: Working with Large Lists in MOSS 2007

Andrew Connell [MVP MOSS] — Wed, 25 Jul 2007 18:27:56 GMT

*** NOW AVAILABLE *** White Paper: Working with Large Lists in MOSS 2007

* NOW AVAILABLE * White Paper: Working with Large Lists in MOSS 2007

Mirrored Blogs — Wed, 25 Jul 2007 18:53:27 GMT

[via SharePoint Team Blog: Scaling to Extremely Large Lists and Performant Access Methods ] This could

* NOW AVAILABLE * White Paper: Working with Large Lists in MOSS 2007

planier — Wed, 25 Jul 2007 20:12:44 GMT

This is *fantastic* information!!

One thing that is noticibly absent from the discussion: SPSiteDataQuery requests. Given thh prevalance and popularity of the Content Query Web Part, this seems particularly relevant.

Are there any other gotchas to be looking for? For instance, custom field types, lookup fields, lists with many different fields or content types, etc? Along the same lines - and per cquick's comment - it would be great to have a very brief discussion of data access methods used by applications such as Access, Excel, Outlook (for offline syncing), etc, as well as by common list interfaces in SharePoint - particularly the CQWP and DFWP/DVWP.

re: Scaling to Extremely Large Lists and Performant Access Methods

Mike — Thu, 26 Jul 2007 05:58:05 GMT

Why do all the OTB web parts shipped with WSS v3 and MOSS implement obsolete connection interfaces? They are multiple articles encouraging utilizing the new interfaces yet they are not programmatically comptabile to be connected with for example a ListViewWebPart. Is it possible that this may change in a service pack?

White Paper: Working with large lists in Office SharePoint® Server 2007

Marwan Tarek's blog — Thu, 26 Jul 2007 10:13:01 GMT

[via SharePoint Team Blog: Scaling to Extremely Large Lists and Performant Access Methods ] Summary:

re: Scaling to Extremely Large Lists and Performant Access Methods

Henry W — Fri, 27 Jul 2007 01:11:22 GMT

Thanks, this info is handy to have when discussing with clients about the strong points and limitation of MOSS 2007.

re: Scaling to Extremely Large Lists and Performant Access Methods

AndrewvR — Fri, 27 Jul 2007 10:26:28 GMT

It would be interesting to know why the browser-based access is so slow (by a factor of 10!). Is it just the rendering/client stuff that uses up the 9x, or does it actually use a different data access method?

Also, it seems to me that there a 2 more tests that would be interesting:

* one for the browser based test where the view being used was grouped/categorised by Expense (I am assuming that the original used the basic flat view)

* a repeat of the tests on a 100,000 item library where the recommended folder structure was in place

(unless I have misread the paper and folder structures were in place - in which case do the tests without the folders)

re: Scaling to Extremely Large Lists and Performant Access Methods

umashinde — Fri, 27 Jul 2007 19:18:59 GMT

This is very useful. What wasn't clear though is the add and delete times and what the tests were. Are there time comparisons for the various ways to add - using web service or SPList.Items.Add()?

re: Scaling to Extremely Large Lists and Performant Access Methods

Michael Reynolds — Thu, 02 Aug 2007 20:23:38 GMT

Great information but as was mentioned in a previous comment it would be great to get some results for accessing data via SPSiteDataQuery. Also, the MOSS CrossListQueryCache object seems to be an efficient way to access list data but that never gets any mention.

re: Scaling to Extremely Large Lists and Performant Access Methods

James — Wed, 24 Oct 2007 18:09:58 GMT

So, would a custom page created in SharePoint designer be considered the Stadnard SharePoint Server 2007 Browser interface? I am using the DataFormWebPart to display list data in a list that could potentially contain 20K records (if we go this direction). So far, I haven't run into any slowness on this page (or when using the default view list page.

We are not currently up to a very large concurrent user base yet, but that number could be increasing in the future when this list is utilized more often (maybe a few hundred concurrent users). Could this be the reason why performance seems ok now?

Things to Consider for SharePoint Performance

Arpan Shah's Blog — Tue, 21 Oct 2008 10:37:13 GMT

SharePoint performance is a function of a number of factors. Some are obvious, some are less obvious,

[转载]SharePoint对象模型性能考量

pccai — Wed, 10 Jun 2009 17:48:26 GMT

SharePoint对象模型性能考量

作者AndreasGrabner译者朱永光发布于2009年6月1日上午3时46分