1. 803: INTO THE WILD
THE CHALLENGES OF CUSTOMIZED
SHAREPOINT APPS IN RELEASE
SPTechCon
2009-06-24, dynaTrace software Inc
Andreas Grabner, andreas.grabner@dynatrace.com
Technology Strategist
dynaTrace

2. About me
• Andreas Grabner
• Technology Strategist
• dynaTrace Software (http://www.dynaTrace.com)
• Blog: http://blog.dynaTrace.com
• Why Performance is such a big topic for me?
dynaTrace 2

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
developer's 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. 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 LOAD
dynaTrace 4

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 setting
dynaTrace 5

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 SharePoint
dynaTrace 6

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 spent
dynaTrace 7

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. 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 work
dynaTrace 9

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. 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. 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
http://blogs.msdn.com/sharepoint/archive/2008/11/12/announcing-
spdisposecheck-tool-for-sharepoint-developers.aspx
• http://msdn.microsoft.com/en-us/library/bb687949.aspx
• http://msdn2.microsoft.com/en-
us/library/aa973248.aspx#sharepointobjmodel_otherobjectsthatrequire-
disposal
dynaTrace 12

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 instances
Monitor SharePoint Memory -> Growing Heap?
Identify who allocates those objects
dynaTrace 13

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. 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
• http://www.sitepoint.com/article/aspnet-performance-tips/2/
• Size matters
• Minimize generated HTML
• Use style sheets instead of inline style definitions
• Enable content compression in IIS
• http://planetmoss.blogspot.com/2007/06/dont-forget-iis-compression-colleague.html
• http://www.sitepoint.com/article/aspnet-performance-tips/3/
dynaTrace 15

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 objects
dynaTrace 16

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
• http://www.sharepointblogs.com/ethan/archive/2007/09/27/generating-test-
data.aspx
• http://www.idevfactory.com/
• http://www.codeplex.com/sptdatapop
dynaTrace 17

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
• http://www.codeplex.com/sptdatapop
dynaTrace 18

19. NEVER TESTED UNDER LOAD
DEMO
• Load Testing SharePoint with Visual Studio Team System
dynaTrace 19

20. Contact me for follow up
• Andreas Grabner
• Mail: andreas.grabner@dynatrace.com
• Blog: http://blog.dynatrace.com
• Web: http://www.dynatrace.com
Participate in Performance Survey
and win a price at the dynaTrace Booth
dynaTrace 20