Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Top 7 mistakes

562 views

Published on

SPTechCon (SharePoint Technology Conference) Austin Texas, February 2015

Published in: Software
  • Be the first to comment

  • Be the first to like this

Top 7 mistakes

  1. 1. Top 7 Mistakes when Building Scalable SharePoint Applications Talbott Crowell ThirdM.com @talbott http://www.freeimages.com/photo/858598
  2. 2. Mistake #1 Conflating Performance and Scalability
  3. 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
  4. 4. Performance A Lamborghini performs well Ferrari is a high performance vehicle http://www.freeimages.com/photo/46549
  5. 5. Scalability A Greyhound bus performs even better than a Ferrari when transporting 100 passengers from Boston to San Francisco https://www.greyhound.com
  6. 6. Example • The application is built on developer machines and performs great (single user) • The application is tested by the QA (quality assurance) team, and they find the performance great (single user) • The application gets deployed into a pilot group of 10 people, the application is still fine because the 10 people don’t use it simultaneously (still effectively single user) • The application is launched and thousands of users start using it and concurrency issues arise
  7. 7. Solution • Add load testing to your SDLC (software development lifecycle) • The earlier the better • Many large Fortune 500 companies have a mandatory stage in their SDLC for volume testing • Adding it into a continuous integration environment is even better • Better catch it early than right before scheduled deployment to production
  8. 8. Mitigation • Strategic • Make sure scalability goals are set early on • Build scalabilty goals into your SDLC • Tactical • Testing tools
  9. 9. Mistake #2 Using SharePoint lists as an OLTP database
  10. 10. 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
  11. 11. Design for the Future Office 365 standard design for Provider Hosted Apps is to use a custom SQL database for your application purposes and to write back to SharePoint lists only when needed
  12. 12. SharePoint 2013 Provider Hosted • Custom Database • ASP.NET development model • Connect to SharePoint using CSOM • Required security token and framework
  13. 13. Mitigation • Strategic • Education on SharePoint Provider Hosteted Apps • Tactical • Build POC’s • Make sure custom DB’s are considered when laying out architecture
  14. 14. Mistake #3 Iterating through SPList
  15. 15. Don’t loop through Lists • Instead use a CAML Query • SPQuery properties: • Query • RowLimit • ViewFields
  16. 16. Demo
  17. 17. Mitigation • Strategic • Add volume testing to all stages of SDLC • Tactical • Code reviews • Education
  18. 18. Mistake #4 Forgetting about Caching
  19. 19. Types of Caching • BLOB caching • Page output cache profiles • Object cache • Anonymous search results cache • Custom code: ASP.NET cache
  20. 20. Caching Consideratins • What can be cached • What is heavily used • What takes up the most time • How long can you cache those items
  21. 21. Multi-server Farm Considerations • If you implement custom ASP.NET caching, and need to “clear” the cache • Make sure there if the same user hits another server it doesn’t still have data cached
  22. 22. Mitigation • Strategic • Make sure caching is part of the SDLC • Tactical • Evaluate different caching mechanisms
  23. 23. Mistake #5 Failing to estimate and test for concurrent user load
  24. 24. Estimate User Load • Document Most Common Use Cases • Weight each Use Case in percentage • Determine Peak User Count • Run load tests on use cases weighted by percentage
  25. 25. When should load test be run? • Answer: the earlier the better • Waterfall: Requirements, Design, Develop, Functional Testing, Load Testing (sometimes too late), Production • Agile: build load test into continuous integration
  26. 26. 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
  27. 27. Mitigation • Strategic • Make load and scalability part of the vision or mission statement for each project • Tactical • Keep a catalog of non-functional requirements • Add this to the checklist so every project requires load estimates
  28. 28. Mistake #6 Failing to account for data growth
  29. 29. 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…
  30. 30. Estimate Volume of Data • After you design your solution estimate what the volume might look like after a year • Load a year’s worth of dummy data • Use PowerShell or C# code • Make sure developer, testers, and pilot users have volume pre-loaded
  31. 31. Mitigation • Strategic • Make load and scalability part of the vision or mission statement for each project • Tactical • Keep a catalog of non-functional requirements • Add this to the checklist so every project requires load estimates
  32. 32. Mistake #7 Not Leveraging Search
  33. 33. Search is very scalable • Very fast response for indexed data • Tune your crawls, best bets, managed properties • Not fast for immediate feedback • Not right solution for all situations • Crawls can sometime take hours/days
  34. 34. Mitigation • Strategic • Increase awareness • Tactical • POC some functionality leveraging search • Make sure to understand indexing and volume time
  35. 35. Final Tip: Know SharePoint Limitations • Web Applications per farm • Site Collections per Web App • Sites per Collection • Lists per Site • Items per List • SharePoint Limitations • http://bit.ly/limits2013
  36. 36. Review 1. Performance vs Scalabilty 2. SharePoint lists not always a good substitute for transactional database 3. For each item in SPList vs CAML Query 4. Caching (many flavors) 5. Concurrent User Load 6. Data volume and growth 7. Make sure to leverage Search
  37. 37. Resources • Office Dev Patterns and Practices on GitHub: http://bit.ly/o365pnp • Bit.ly Bundle: https://bitly.com/bundles/talbott/2 • Blog: http://talbottcrowell.wordpress.com/ • Twitter: https://twitter.com/talbott Talbott Crowell ThirdM.com @talbott

×