개발이 끝나는 무렵… 이제 성능 테스트와… 벌래(bug)를 찾아 삼만리 하게 됩니다.
쉐어포인트에는 참 좋은 성능 확인과 벌래 잡이용 대시보드라는게 있습니다.
일단 실행은 아래와 같이 입력하시면 됩니다.
Sharepoint 2010 Management Shell을 실행하고..
아래와 같이 입력하시면 됩니다.
시작 stsadm -o setproperty -pn developer-dashboard -pv on 종료 stsadm -o setproperty -pn developer-dashboard -pv off
위의 내용은 아래 링크에서 좀 더 자세히 볼 수 있습니다.
http://msdn.microsoft.com/en-us/library/ff512745.aspx
그리고 실행하게 되면 아래와 같은 화면을 볼 수 있습니다.
여기에서 좌측의 노란 색 영역은 현재 페이지에 실행되는 액션 대비 시간이라고 생각하시면 되고..
우측의 상단 빨간색 영역은 오류내용을 표시합니다.
선택 시 좀 더 자세한 내용을 확인 할 수 있고요..
빨간 색의 내용 중 90hv에 관한 내용은 이전에 적어 놓은 포스트에서 확인 하시기 바랍니다.
그리고 마지막 우측하단 파란색 영역은 실행된 모든 프로시저에 관한 내용을 확인 할 수 있습니다.
여기 프로시저에서 중요한 내용이 있는데..
DECLARE @DocParentIdForRF 라고 되어 있는 프로시저의 경우에는 한번씩 확인을 해 줘야 합니다.
해당 프로시저를 선택하면 위와 같이 자세한 내용을 볼 수 있습니다.
제가 하이라이트 표시 해 놓은 부분에 만약 SELECT TOP (@NUMROWS) 라고 되어 있다면 @NUMROWS의 VALUE도 확인하셔야 합니다.
아래와 같이 2,147,483,648 으로 설정될 수 있습니다.
성능상의 문제가 될 수 있는 요인이 있기 때문에 반드시 확인하셔야 합니다.
해당 코드는 대략 아래와 같이 구분 할 수 있습니다.
- SP Item의 인덱스 접근 말고 GetItemById 등과 같은 코드로 접근 할 것
- item = targetList.Items[int]; X
- item = targetList.GetItemById(int); O
- SPQuery 사용 시 반드시 RowLimit를 지정 할 것!
- Query.RowLimit = 10;
- 게시판의 카운트를 구할 때 List.ItemCount 와 같이 접근 할 것
- int total = SPContext.Current.List.Items.Count; X
- int total = SPContext.Current.List.ItemCount; O
위와 같이 해 주시면 저런 21억 Row 쿼리가 실행 되지 않습니다.
그리고 위의 화면에 짤린 부분이 있습니다.
이 부분인데 Service Calls 부분에서 WebPart Events Offsets 부분만 확인하시면 됩니다.
여기에는 각 웹파트 별로 OnLoad 시점의 시간이 나타나게 되는데요…
급격히 증가하는 웹파트를 찾아서.. 튜닝해 주는 방법을 이용하시면 됩니다.
이렇게만 확인해 주셔도.. 페이지의 로딩시간 단축을 확인 할 수 있습니다.
이상입니다.
고맙습니다.
