Building high performance and scalable share point applications

  • Published on

  • View

  • Download

Embed Size (px)


SharePoint custom application development can sometimes be challenging. This presentation at SPS New Hampshire on October 18th, 2014 covers some techniques and strategies on improving performance and scalability of your applications.


<ul><li> 1. Building High Performance and Scalable SharePoint Applications Talbott Crowell @talbott </li> <li> 2. AGENDA Terminology Where Performance occurs in the SDLC Test Cases, Use Cases, Volume of Data SharePoint Limits OOTB or Custom? Provider Hosted Apps Know SharePoints Strengths What to Avoid Developer Dashboard Instrumentation Phases of SDLC </li> <li> 3. Terminology Performance Behavior and response time for a single user or multiple users under load Scalability Behavior and response time for a growing number of users and volume under load </li> <li> 4. Performance A Lamborghini performs well </li> <li> 5. Scalability A Greyhound bus performs even better than a Lamborghini when transporting 100 passengers from Boston to San Francisco </li> <li> 6. Software Development Life Cycle Waterfall Agile Combination What's missing from this graphic? Testing! Functional Testing Performance Testing Scalability Testing </li> <li> 7. NON-FUNCTIONAL REQUIREMENTS Make sure you have: Performance requirements Maximum page load time Time for a user to complete a use case Volume requirements How much volume of data will your solution store at launch, 6 months after launch, 2 years after launch? How many people will use your application Scalability requirements Number of concurrent users + volume + real world use cases </li> <li> 8. TEST CASES Know BEFORE you start designing, even before you are laying out the solution architecture what a real world scenario will look like 1. Use cases 2. Number of users 3. Volume of data </li> <li> 9. Use Cases Doesn't need to be specific to the implementation Just describe a user and the high level operations they need to perform Examples user logs into the system and finds a purchase order user updates a purchase order by assigning date paid Don't need to have details of how the user will accomplish the use cases, just what the user does </li> <li> 10. Number of Users How many users will be using your system? How often will they be using the system? How many people will be using the system concurrently? Look at logs/stats for similar applications at the company What about peak times? Example: Recording timesheets, there might be a peak load in the last few hours they are due, Friday from noon to 6 PM </li> <li> 11. Volume of Data Application might perform just fine with one to ten Purchase Orders, but what happens when there are hundreds of thousands? Know your target volume Simulate that volume using scripts Make sure at every step of the way, volume is considered: envisioning, designing, implementing, testing </li> <li> 12. SharePoint Limitations Number of Web Applications on a farm Number of security groups and users, especially when breaking permission inheritance for site level, list level, or item level security Number of items in a list 30 million items per list </li> <li> 13. IS 30 MILLION ITEMS A GOOD IDEA? Just because it is possible, should you build your information architecture and/or application solution architecture on these limitations? IT ALL DEPENDS! How are you going to use those items? SPQuery? SPSiteDataQuery? CrossListQueryInfo? (Enterprise Edition) Search index and Search API? </li> <li> 14. OOTB OR CUSTOM? Out of the box SharePoint functionality Lists Automatic CRUD screens for free Easy to set up Can handle many situations Custom solutions Database More development time May perform/scale better in certain situations </li> <li> 15. SOLUTION ARCHITECTURE SharePoint stores data in lists Lists are abstractions that are physically represented as records in the content database If you are building an application in SharePoint, consider the options in storing the data in its own database SQL </li> <li> 16. SHAREPOINT ONLINE VERSUS SHAREPOINT ON PREM Fully Trusted Code is not allowed on Office 365 More flexibility on premise Higher maintenance cost for on premise </li> <li> 17. SHAREPOINT 2013 PROVIDER HOSTED Custom Database ASP.NET development model Connect to SharePoint using CSOM Required security token and framework </li> <li> 18. Know SharePoints Strengths Search is very powerful Leverage for very quick results retrieving from large sets of data Take in account the time to index the data Does it take 15 minutes or a day to crawl your data set? </li> <li> 19. AVOID Looping though items Use targeted CAML queries instead with SPQuery, SPSiteDataQuery, etc.. Using Web Parts when they arent needed Web parts are great for composable pages or reusable components Throwing Exceptions for normal flow Exceptions should be used when something exceptional goes wrong (network is down, database is unreachable) Very slow, and cause major performance issues </li> <li> 20. DEVELOPER DASHBOARD Free tool for analyzing web pages in SharePoint Turn it on in developer environments (Get-SPFarm).PerformanceMonitor.DeveloperDashboardLevel = On Can turn it on in stage/production when needed to troubleshoot in realtime Leverage SPMonitoredScope </li> <li> 21. INSTRUMENTATION Leverage ULS logging Implement your own logging Incorporate a third party logging or instrumentation product or framework </li> <li> 22. PHASES PART 1 Envision Gather Non-functional requirements Volume, user count, and use cases Design Keep in mind the volume and scalability POC areas you arent sure of Develop Build out the system Use tools like developer dashboard </li> <li> 23. PHASES PART 2 Test Make sure to test with artificial volume of data functional (does it work) performance (does it meet required user experience response times) scalability (does it handle load) You may need load tools for this Large corporations have load tools and teams Smaller companies will rely on devs or QA Visual Studio has load tools </li> <li> 24. PHASES PART 3 User Acceptance Pilot Production Monitor Leverage instrumentation Maintenance Fix performance and scalability issues before your users notice them Proactively look at error logs for ways to clean up </li> <li> 25. REVIEW What is faster, a lambo or a bus? When should you be thinking about performance and scalability? </li> <li> 26. RESOURCES Bundle: Blog: Twitter: Office Dev Patterns and Practices on GitHub: </li> <li> 27. Was made possible by the generous support of the following sponsors And by your participation Thank you! </li> <li> 28. Join us for the raffle &amp; SharePint following the last session Be sure to fill out your eval form &amp; turn in at the end of the day for a ticket to the BIG raffle! </li> </ul>