SharePoint 2010 Performance – Identifying Pain Points
Performance is the most important exercise for any application. Most of the applications pass through performance issue after releasing to the customers and end users. When you are running the application for single user, you can’t see any performance issues. But the same application running for days, weeks, months and years then end users sees the difference in the performance.
Working on performance improvement for a SharePoint is a really a painful task. SharePoint internally having performance issues so when we are working on performance of the application we have to utilize all possible options that SharePoint provide and then we have to look at the pages that we are creating as part of the application which are killing the performance.
In this document I am going to talk about tools to identify pain points, analyzing the pain points and suggesting most suitable solutions.
I am preparing this document based on the experience that I got from the projects that I worked so far. I am not a SharePoint architect or expert so most of the solutions that I am proposing in view point of web application.
2. Identifying Performance Bottlenecks
To work on performance improvements for any application first and foremost activity that everyone has to do is, identifying problematic areas in your application and identifying the performance of the application before making changes to the application.
2.1. Measuring performance of the application
2.1.1. Enable Developer Dashboard.
SharePoint provides developer dashboard functionality to know the performance of the application. It provides complete execution time for the application. The execution time that shows on the develop dashboard are request processing time at server.
If you are having different web parts on the page then you can get each web part execution time on the developer dash board. So to know the complete application execution, enable developer dash board and see the execution plan.
Below are the power shell commands to enable developer dash board.
stsadm -o setproperty -pn developer-dashboard -pv on
(Get-SPFarm).PerformanceMonitor.DeveloperDashboardLevel = ”On”
2.1.2. Using HTTP Watch or Fiddler
You have to install these tools in your machine, start the application before hitting and SharePoint page. These tools provide response time; download response size, number of internally request and time taken to process each request.
By using these tools you can see total time taken to download content to the client browser. So you can see what exactly client feel for the response of the request. These tools also provide response object size and all internal download requests.
2.1.3. IIS Logs
Every request that process at IIS, will log complete request details along with execution time. Verifying each request execution time using HTTP watch or fiddler or developer dash board is not so easy. To identify the problematic pages in your application you have to use and analyze IIS logs. By analyzing one day or one week or one month logs you can list down all pages which are taking more time to execute, and test those pages using developer dash board or fiddler or HTTP watch to know more details.
Use Logparser software to analyze IIS logs. If you are using log parser software then use below query used to get requested data in the CSV format, which is most comfort format to verify all request.
logparser “select date,time,time-taken,cs-uri-stem from ‘D:\Logs\test1.log’ where time-taken >5000 order by time-taken” -e:10 -o:csv -i:W3C >> “D:\Logs\test1.csv”
The above query will fetch all requests which are taken more than 5 seconds in test1.csv file.
2.1.4. .NET Profilers
Run memory and execution related profilers on your custom code. To get more inner details about your code, build you code in debug mode and run profilers on your code. Look at time taken for each block of code and see which block is taking more time. Memory profilers provide data about memory leaks and number objects used and their sizes. Best profiler that I used is ANTS profiler.
2.1.5. SQL Profilers
SQL profiler provides data about the queries that are running or ran on the SQL server. Profilers capture execution time along with execution plan for the query.
To collect the data, run SQL server profiler where SharePoint SQL server configured before users hitting the application. Start and stop recording for a particular span of time, but most preferable way of collecting right data is by doing this operation after collecting data from IIS Logs.
2.2. Identifying bottlenecks
2.2.1. Analyzing IIS Logs
For identifying most problematic pain points in the application then first and far most thing that we can do is, analyzing IIS logs.
- 1. Capture IIS logs for a period of time
- 2. Ran log parser to collect the pages taking more than business execution time (5 sec or 10 sec)
- 3. Collect pages taking more time among all the pages.
- 4. Along with the execution time, collect the page which are having response size more than 500KB
Information that you collected using above process provides most important pages where we have to start working on performance.
List down all the pages those are taking most of the execution time and prioritize the page by execution time and number of hits.
2.2.2. Analyzing fiddler or HTTP watch traces
After collecting data using IIS logs, open those pages from browser by running fiddler or HTTP watch to see user response time, response object, number of internal request and types of data downloading. Then look at below components to see the actual problem
- 1. Look at each requests internally called when user requested for a page and calculate time taken for each individual request
- 2. Verify number of images or CSS or JS files downloaded and total time taken for these requests
- 3. Actual time taken for the page request.
If the page is taking more time to process then those pages to be analyzed using developer dash board. Also calculate total time taken for other internal request to minimize total response time for end user.
List down all the pages those are taking most of time to load in client machine.
2.2.3. Analyzing Developer Dash Board
Open pages which are taking more time to respond to the end user in the browser and enable developer dash board. Developer dash board will come below the actual page content. It contains time taken to execute the page and each web part. By look at each web part execution time you can clearly point out which web part is consuming most of the execution time. If there is no web part then you have to look at the page what exactly it contained and how it’s displaying content to the end user.
List down all web parts those are taking most of the execution time.
2.2.4. Analyzing SQL Profilers
Open pages which are taking more time to respond, before browsing page, start SQL profile on your data base. After browsing the page, stop the profiler and see the number of queries executed for the request and verify time taken for each request. Along with query execution verify amount of data fetched for each query.
Then look at queries for below data
1. Taking more time to execute
2. Queries without where clause
3. Queries which are fetching huge data
4. Queries which are executing most number of times
5. Identify queries which are related to your code.
No comments yet.