SharePoint 2010 Performance – Improvement Steps
1. Performance Improvement Steps
1.1. Architectural Changes
Below are the most important architectural points to be verified. Verify your application architecture with these points.
1.1.1. SharePoint data base and server should not be on same system
Use external system data base for configuring SharePoint and your application. In this way you can distribute load on different servers. When you are using external data base make sure that no other services or components running on that machine apart from SQL Server components.
1.1.2. Manage metadata should be configured on different server.
Similar to previous point, by configuring manage metadata on different server you can reduce the load on your server. But when the application has huge term store and using more taxonomy fields then go for this option. Or else you will degradation in your performance by this approach.
When creating term store makes sure that there won’t be more than 7 sub levels. As the number of sub level increases complexity of term store increase and it takes more time to fetch data using metadata service.
1.1.3. Custom Features
Create solutions specific to application (Sandbox) instead of public (farm) solutions. When you are creating more solutions for different purposes to install at different sites and sub sites then create solution based on the each individual functionality. When you are developing the features to be used for entire application (sites and sub sites) then do high level separation and install the features, instead of making a feature for individual functionality.
1.1.4. Connectivity between Systems
All systems must be closely connected in single network if possible with internal direct cabling. It will reduce network latency. When application is small and targeting to limited users then entire application can be hosted in single server.
1.1.5. Search Configuration
Search has to be configured on different machine and crawl data has to be stored in different server than SharePoint server. When crawl is running there will be less load on the server.
1.2. Application Configuration Changes
1.2.1. SharePoint Health analyzer
Verify health analyzer rules, and add if you want to any new rules to it. Configure rules with auto resolve the issue wherever possible. If issues are not auto resolve try to see possible solution and rectify them.
Enable cache on the application. SharePoint provide different cache techniques and enable all possible caches. When you are enabling cache on your application make sure that your application server having huge RAM and enough space. The idlest way of having RAM is 32GB and free space on C drive is 64GB.
The cache normally get refreshes whenever application pool restarts or huge content added to the application. By using cache we can get better performance but for the first hit after cache refresh will take longer time than usual.
1.2.3. Customize SharePoint logs
Customize SharePoint logging to log most import data instead of writing everything and clearing old logs from the server. By this way you can control IO operations.
1.2.4. Enable IIS Compression
Enable IIS compression at IIS level. When you are dealing with huge content on the page then go for 5-7 compression level. Make dynamic compression at 5-7 and static compression at 10. But this option gives more value to the application when application running over internet or across different intranet zones.
1.2.5. Resource throttling settings for Web Application
By enable resource throttling, you can restrict number data object to be fetched or updated at a time. This will be used when your application having huge number of pages or content.
1.2.6. Target Audience
Disable target audience service if your application is not using it. But this change has to be done only when application is not using target audience feature. It will reduce level of security check.
1.3. Code Optimization
1.3.1. OOTB Web Parts
188.8.131.52. Extended Content Query Web Part
When you are using extended content query web part to display any list data then you have to follow below things.
1. Don’t try to fetch data from sites and sub sites, if you are trying to get then make sure that you don’t have more sites and sub sites.
2. Use XSLT to present the data on the web part. XSLT are much faster and light weight when compare to data grids.
3. If data is fetching from different sites and sub sites to display then go for custom search web part instead of extended content query web part.
184.108.40.206. Search Web Parts
When application using different search web parts then make sure that search configured and crawl is running and storing on different server than SharePoint server. Search web parts gives much better performance than other web parts.
220.127.116.11. List View Web Part
When application using list view web part then create different views on the library and use that library for the list instead of showing everything. But creating custom view, you can minimize data that you have to display on the web part as well as amount of data that you fetch from the library or list.
1.3.2. Custom Web Parts
Custom web parts are 2 kinds
18.104.22.168. Extending OOTB Web Parts
OOTB web part extends to override a particular behavior or add another level of criteria. So when you are extending OOTB
1. Don’t break the existing behavior of the OOTB web part
2. When are looking for custom property add it from elements.xml and use that property in the code
3. When you are reading any data from the list or library make sure that you are reading only required data with columns list and criteria with order if required.
4. Use XSLT to present the data where ever required instead of grid controls.
22.214.171.124. New Custom Web Parts
Custom web parts has to follow below steps while developing
1. Design complete component.
2. Separation BL and DAL from presentation.
3. Optimized queries and most preferably use store procedures.
4. Run profilers to see execution time.
5. Use XSLT instead of grids.
6. Disable view state if you are not performing any use actions.
1.3.3. Asynchronous Web Parts
Asynchronous web parts reduce request time. This approach won’t bring much performance to the application but end user can see partial data on the page while loading rest of web parts. To execute web parts asynchronously, all web parts must develop on asynchronous framework. When you are using search web parts, by default these provide asynchronous execution. But when there is more number of web parts running on a page in asynchronous mode, and then there will be lot of load on the server. In long run it degrades the performance. So when we are making any web part as Asynchronous make sure that
1. Web part consuming more time to fetch the data.
2. End user can wait for data to be load.
3. And there won’t be more number of pages or web parts on a page.
1.3.4. Optimizing Code
Developers can utilize all .NET optimization techniques, and can run profilers on the code and verify the performance of the application. Most common points to be validated while coding are
1. Declare variable whenever required
2. Use specific types of variables
3. Destroy objects
4. Reduce type casting where ever possible
5. Minimize loops and recursive calls
6. Don’t call garbage collect
7. Don’t throw exceptions; re throw exceptions are much costlier in terms of memory consumption and execution.
8. Minimize exception handling blocks, use exception block where ever you are not able to handle or pretend exceptions.
9. Minimize class size (number of methods, logic, variables…. etc.) and follow better suitable component design.
1.4. Data Base Optimization
1.4.1. Writing SPs
Write stored procedures instead of different queries. If you have a block of code which completely deals with data base then move that code block to SP instead of writing in .NET
1.4.2. Optimizing Queries
When you are writing any query make sure that you are specifying column names and where clause. Whenever you are writing any query make sure that you are running that query for execution flow. In the execution flow you have to see time taken to process the request and number of bytes transfer while execution. When you are considering best optimized query then you have to consider both parameters. All less time execution queries won’t give performance in long run as well as less byte transfer queries won’t bring performance. So both parameters to be in particular range. If you are not very clear on your query always reach out your DB specialist.
1.4.3. Minimizing number of Queries
This can happen in 2 ways
1. Query can be called from different places for same purpose. Then better save that value in a global value by fetching at once and use across the application.
2. Query can be called with change in where clause. Then use named parameters when you are querying. The reason why I am suggesting the named parameters is, whenever user queries to the data base it compiles the queries and then executes. When user calls the same query then it uses compiled block to execute the query. So there won’t be compilation for the same query. If the query is changing with different values in the where clause normally SQL treats all queries as different and compiles every time. Instead of that if you use named parameters query will be compiled with names values and user can pass different values to the named parameters.