2009-06-11 3 views
2

약 3000 개의 항목이있는 목록이 있습니다. 편집 페이지는 영원히로드되지만 나머지 사이트는 빠릅니다. 페이지에서 조회 열을 사용하고 다중 선택 드롭 다운을 사용하는 것과 관련이 있다고 생각했지만 교체 후 아무런 차이가 보이지 않습니다.사용자 지정 공유 목록 추가/편집 페이지로드가 느립니다.

페이지는 약 118kb이며로드하는 데 약 5 분이 걸립니다.

속도를 높이거나 원인을 파악하는 방법에 대한 아이디어가 있습니까?

ASP.NET 또는 IIS (응용 프로그램 풀을 더 빠르게/더 느리게 재사용합니까?)에 대한 제안 사항이 있으면 알려주십시오.

답변

2

SharePoint에서 목록을 사용하여 작업 할 때는 적절한 성능을 보장하는 최상의 방법을 따라야합니다. 내가 겪고있는 문제가 목록의 항목 수에 기인 한 것이 아니라 처리하는 데 사용하는 UI의 제한 사항 (페이지 추가 및 편집)이 아니라고 생각합니다.

추가 및 편집 페이지를 사용해야하는 경우 약 2000 개의 항목으로 제한해야합니다. 목록에 폴더를 추가하여 목록에 보관할 항목의 수를 늘릴 수 있습니다.

목록에 실제로 항목이 더 필요한 경우 목록에 대한 고유 한 UI를 구현하고 SPQuery를 사용하거나 다른 방법을 사용하여 결과를 쿼리하는 것을 고려해야합니다. 이 경우 동일한 성능 문제가 발생하지 않으며 잠재적으로 100.000 이상의 항목을 보유 할 수 있습니다.

Microsoft는 SharePoint의 목록 작업에 대한 성능 테스트 결과를 제공하는 백서를 발표했습니다. 여기 백서 링크가 Working with large lists in Office SharePoint® Server 2007

+0

당신은 모두 나를 때리 겠지만 제가 3000 개의 항목을 말했을 때, 나는 폴더를 언급하고있었습니다. * 실행 * 문제는 누군가 다른 사람이 시작한 후에이 프로젝트에 들어 왔고 무엇을해야하는지에 대해 "지시를 받았다"는 것입니다. 처음에는 모든 데이터가 목록에 덤프되었습니다. 나는 그것을 폴더로 바꿀 수 있었다. UI를 직접 작성할 수 있으면 좋지만 불행히도 그건 내게 달린 것이 아닙니다. : - <당신이 제공 한 종이 링크는 굉장합니다. 감사. – AboutDev

2

목록에는 모범 사례로서 그 안에 많은 항목이 없어야합니다. 나는 목록을 리팩토링하여 처음부터 좀 더 관리하기 쉬운 것으로 만들 수있는 방법을 찾고 있습니다.

당신이 정말로 목록이 큰 처리해야하는 경우, 내가 출력 캐싱에 보이는 것

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

+0

확인. 해당 목록에 대한 추가 및 편집 페이지를 캐시하는 방법이 있습니까? – AboutDev

+0

성능 문제를 일으키는 것은 물리적 추가/편집 페이지 자체가 아니라고 생각합니다. 편집 페이지를 열 때마다 목록 항목과 연결된 메타 데이터를 가져 오기 위해 CAML 쿼리가 실행되고 있습니다 (edititem.aspx 페이지의 쿼리 문자열을 보면 큰 GUID에서 단일 항목을 참조해야 함) 목록) –

+0

나는 그것에서 3000의 품목 이상 잘 명부가 있었다. 나는 너 안에있는 물건의 숫자가 너의 문제인지 의심 스럽다. –

1

는이에 정의되어 있는지 확인하기 위해 SharePoint 디자이너에 추가/편집 페이지를 열었습니다 어떤 방법으로? 어쩌면 그것은 당신에게 단서를 줄 것입니다.

언제든지 열의 색인을 가지고 놀 수는 있지만 어떻게 도움이되는지는 알 수 없습니다. 편집에 사용되는 ID 열은 자동으로 색인화되어야하며 추가 화면으로 이동하는 데 영향을주지 않아야합니다.

+0

예. 추가/편집 페이지가 사용자 정의되었습니다. 그러나 대부분의 사용자 정의는 항목의 순서를 올바로 지정하고 일부 구두점을 추가하는 것입니다. 인덱스를 어떻게 사용합니까? 나는 콘텐츠 db와 AllUserData 테이블을 안다. 인덱스를 수정해야하는 테이블입니까? – AboutDev

+0

목록 열 인덱스에 대해서만 이야기했습니다. 나는 이것이 여전히 도움이 될 것이라고 생각하지 않지만 목록 설정 페이지로 가서 Indexed Columns (컬럼 섹션 아래)를 클릭 할 수 있습니다. 그러면 색인을 생성 한 열이 표시됩니다. ID 열은 자동으로 색인 생성됩니다 믿을 수있는 옵션이 아닙니다. 기본 추가/편집 페이지로 돌아가서 성능 향상에 도움이되는지 확인해야한다고 생각합니다. 그렇다면 사용자 정의를 자세히 수행해야합니다. –

+0

예, ID가 표시되지 않습니다. 아마도 두 개의 조회 필드를 인덱싱하는 것을보고 있었지만 자동으로 완료되었다고 추정합니까? – AboutDev

2

수정되었습니다. 200,000 개가 넘는 항목이있는 목록에서 조회를 수행하는 조회 열을 숨기는 것이 수정되었습니다. editform.aspx의로드 시간은 평균 1 분 15 초에서로드 2 ~ 3 초입니다.

관련 문제