views:

3001

answers:

3

I have a list with about 3000 items in it. The editing page is taking forever to load but the rest of the site is fast. I thought it had to do with having a Lookup column on the page and using the multiselect drop down but after replacing it, I am seeing no difference.

The page is about 118kb and take about 5 min to load.

Any ideas on how I can speed this up or go about figuring out the cause?

If you have suggestions for ASP.NET or IIS (recycle the app pool faster/slower?) changes please let me know.

+2  A: 

Lists really shouldn't have that many items in them, as a best practice. I'd work for a way to refactor your lists into something more manageable for a start.

If you really must deal with this large of list, i'd look into output caching

http://technet.microsoft.com/en-us/library/cc298466.aspx

Jason Watts
Ok. Is there a way to cache JUST the Add and Edit page for that list?
AboutDev
I don't think that it's the physical add/edit pages themselves causing the performance problems. It's the fact that a CAML query is being executed to get the metadata associated with a list item every time you open the edit page (look at the query string of the edititem.aspx page, you should see a large GUID referencing a single item from the list)
Jason Watts
I have had lists with well over 3000 items in it. I doubt the number of items in your is your problem.
Kirk Liemohn
Kirk, I agree; this could even be a hardware limitation (perhaps a 32 bit db server, or configuration issues with sql?)This question will probably need more config detail to be answerable.
Jason Watts
Its a Win x64 machine and I'm not sure about the SQL Server. Its a large company so I'm hazarding a guess here but I believe its a Active-Passive configuration. There is only 1 front end. What really baffles me is why EVERYTHING else on the site is fast EXCEPT these 2 Add/Edit pages. Yes they are customized but the ADD page does not bring any info back...so why does it slow down and take 80+ seconds to load.
AboutDev
+1  A: 

Have you opened the Add/Edit page in SharePoint Designer to see if it has been customized in some way? Maybe that will give you some clues.

You can always play around with indexes on your columns, but I don't see how that would help. The ID column used for Edit should be indexed automitically and they should have no effect for navigating to the Add screen.

Kirk Liemohn
Yes the Add/Edit page has been customized. However, most of the customization is to just get the order of items correct and add some verbiage. How do I play with the indexes? I know the content db and the AllUserData table. Is that the table whose indexes I should modify?
AboutDev
I was just talking about the list column indexes. I still don't think this will help, but you can go to the list setting page and click on Indexed Columns (down below the columns section). This will show you which columns you have indexed. The ID columns is not an option as I believe that is automatically indexed.I think you should try to revert back to the default add/edit page and see if that helps with performance. If so, then you need to go through your customizations in detail.
Kirk Liemohn
Yeah ID's don't show up there. I was looking at perhaps making the two Lookup fields indexed but I presume that its automatically done?
AboutDev
+2  A: 

When working with lists in SharePoint you should follow the best practices to ensure an acceptable performance. I don't think the issue you are experiencing is not caused by the number of items in the list, but rather on the limitations on the UI you are using for handling them (Add and Edit page).

If you need to use the Add and Edit page, you should stick to a limit of around 2000 items. You can always add additional folders to your list and in this way increase the number of items to hold in the list.

If you really need more items in a list, you should consider implementing your own UI for the list and query the results using SPQuery or using other methods. In this case you will not run into the same performance issues and could potentially hold 100.000+ items.

Microsoft has released a white paper with the results of a performance test for working with lists in SharePoint. Here is a link to the white paper called Working with large lists in Office SharePoint® Server 2007

Thomas Favrbo
You're all going to hit me but when I said 3000 items, I was referring to folders. *runs*The problem is that I came into this project after someone else had started it and I was "instructed" on what to do. Initially ALL their data was just dumped into the list. I managed to change it to folders. I wish I could write the UI myself but unfortunately, that is not up to me. :-< The paper link you provided is awesome. Thanks.
AboutDev