SharePoint TechCon 2009 - 803


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

SharePoint TechCon 2009 - 803

  1. 1. 803: INTO THE WILD THE CHALLENGES OF CUSTOMIZED SHAREPOINT APPS IN RELEASE SPTechCon 2009-06-24, dynaTrace software Inc Andreas Grabner, Technology StrategistdynaTrace
  2. 2. About me • Andreas Grabner • Technology Strategist • dynaTrace Software ( • Blog: • Why Performance is such a big topic for me?dynaTrace 2
  3. 3. Agenda • This class will examine the real-world challenges of customized SharePoint applications when they are released “into the wild.” We will consider why such applications almost always work on the developers machine—and why they often fail in production. Web parts and lists are the main focus in this advanced class • LOTS OF DEMOS!!dynaTrace 3
  4. 4. Why do we end up with performance problems? • TOO MUCH data is requested • Data is REQUESTED in an INEFFICIENT way • INEFFICIENT use of RESOURCES • INEFFICIENT data RENDERING • NEVER TESTED with REAL WORLD data • NEVER TESTED UNDER LOADdynaTrace 4
  5. 5. TOO MUCH data is requested • SharePoint Lists • Only display the data that the user really needs to see • Limit the number of rows that are displayed in the ListWebPart • Use Views to limit the number of columns that are displayed • Use alternative WebParts • Sometimes the ListWebView is not the right way to go • Check the size of returned html page • Consider the overhead on the network/browser rendering time • SharePoint Indices • Speed up access to large lists • Require additional resources on database • Only first index column is used in a View‘s Filter settingdynaTrace 5
  6. 6. TOO MUCH data is requested • Optimize Lists based on Usage • Analyze Usage of Lists & Views and optimize on slowest performing Analyze usage and performance of all lists in SharePoint Analyze usage and performance of all views in SharePointdynaTrace 6
  7. 7. TOO MUCH data is requested • Custom Web Parts • Accessing Data via SharePoint Object Model • Understand what is going on when accessing Data via API • Use SPQuery‘s to access only the data you need to display • Cache Data • Think about caching data that doesn‘t change frequently Analyze where WebParts spend their time and how they access the data Analyze where most of the time is spentdynaTrace 7
  8. 8. TOO MUCH data is requested • Recommendations from SharePoint Product Team • Monitoring • Processor: % Processor Time: _Total. On the computer running SQL Server, this counter should be kept between 50%-75%. • System: Processor Queue Length: (N/A). Monitor this counter to ensure that it remains below two times the number of Core CPUs. • Memory: Available Mbytes: (N/A). Monitor this counter to ensure that you maintain a level of at least 20% of the total physical RAM free. • Memory: Pages/sec: (N/A). Monitor this counter to ensure that it remains below 100 • ... • SQL Server practices • Proactively check the integrity of your databases by running DBCC CHECKDB (‘<DB Name>’) on a routine basis • Monitor SQL Server index fragmentation • Do not perform unsupported operations on the server running SQL Server • Reference • Search for „Planning and Monitoring SQL Server Storage for Microsoft SharePoint Products and Technologies: Performance Recommendations and Best Practices“dynaTrace 8
  9. 9. TOO MUCH data is requested DEMO • How to analyze current list usage behavior? • How to analyze WebPart data access? • Comparing Performance Impact when changing Views • How indexed columns really workdynaTrace 9
  10. 10. Data is REQUESTED in an INEFFICIENT way • SharePoint Object Model • DO NOT iterate through all items in the list • DO NOT access the Items property multiple times • AVOID using the Count property • Use CAML Queries and SPQuery‘s to select certain data • Use the RowLimit and ListItemCollectionPosition Feature of SPQuery Example: Query the Product Name of a certain Product identified by the Product ID DO NOT String productName = productList.Items.GetItemById(“1234“)[“ProductName“].ToString(); DO String productName = productList. GetItemById(“1234“)[“ProductName“].ToString(); or DO SPQuery query = new SPQuery(); query.Query = "<Where><Eq><FieldRef Name=ID/><Value Type=Text>1234</Value></Eq></Where>"; String productName = productList.GetItems(query)[0][“ProductName“].ToString(); DO BEST query.ViewFields = “<FieldRef Name=‘ProductName‘/>“;dynaTrace 10
  11. 11. Data is REQUESTED in an INEFFICIENT way DEMO • Whats going on „under the hood“ when using the SharePoint Object Model? • How to improve SharePoint Data Access?dynaTrace 11
  12. 12. INEFFICIENT use of RESOURCES • SharePoint Object Model • SPSite and SPWeb hold references to native COM objects • Release SPSite & SPWeb in order to free native resources • Querying too much data results in high memory usage • Reference • SPDisposeCheck tool spdisposecheck-tool-for-sharepoint-developers.aspx • • us/library/aa973248.aspx#sharepointobjmodel_otherobjectsthatrequire- disposaldynaTrace 12
  13. 13. INEFFICIENT use of RESOURCES • Monitor resources • Monitor Memory • Monitor Database connections • Monitor „critical“ SharePoint objects (SPSite, SPWeb) • Identify leaking responsible WebParts Identify „leaking“ object instancesMonitor SharePoint Memory -> Growing Heap? Identify who allocates those objectsdynaTrace 13
  14. 14. Data is REQUESTED in an INEFFICIENT way DEMO • How to identify a SPSite/SPWeb Resource Leak? • How to identify resource intensive WebParts? • How to monitor SharePoint Memory Issues down to the Object Model‘s Data Access classes?dynaTrace 14
  15. 15. INEFFICIENT data RENDERING • How to render data • StringBuilder vs. String concatenations • Use HtmlTextWriter for custom WebParts • How to access data • Follow the rules discussed earlier • ViewState • Monitor ViewState Usage • • Size matters • Minimize generated HTML • Use style sheets instead of inline style definitions • Enable content compression in IIS • • 15
  16. 16. INEFFICIENT data RENDERING • Steps to do • Analyze slow pages with tools like YSlow • Analyze network infrastructure. Compare server side times vs. Client side times Analyze Page Size Statistics Analyze individual page objectsdynaTrace 16
  17. 17. NEVER TESTED with REAL WORLD data • Importance of Test Data • 10 records in a table are not enough • Invest time to generate Test Data • „Random“ data is good -> „Realistic“ data is best • Test Data must be used by developers • Many data access problems can be identified on the developers machine with appropriate test data • Problems that can be identified • Performance problems for data retrieval • Index problems • Memory issues • Resource bottlenecks • Resources • data.aspx • • 17
  18. 18. NEVER TESTED UNDER LOAD • Importance of Load Testing • Small load tests already on developers machine • Test as early as possible • Test main use case scenarios • Visual Studio Team System for Tester • Pre-configured Web&Load Tests from the SharePoint Team • dynaTrace Integration with VSTS to analyze performance and scalability issues • Resources • 18
  19. 19. NEVER TESTED UNDER LOAD DEMO • Load Testing SharePoint with Visual Studio Team SystemdynaTrace 19
  20. 20. Contact me for follow up • Andreas Grabner • Mail: • Blog: • Web: Participate in Performance Survey and win a price at the dynaTrace BoothdynaTrace 20