SPTechCon (SharePoint Technology Conference) Austin Texas, February 2015

1. Top 7 Mistakes
when Building Scalable SharePoint
Applications
Talbott Crowell
ThirdM.com
@talbott
http://www.freeimages.com/photo/858598

2. Mistake #1
Conflating Performance and
Scalability

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. Performance
A Lamborghini
performs well
Ferrari is a high
performance vehicle
http://www.freeimages.com/photo/46549

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. 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. 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. Mitigation
• Strategic
• Make sure scalability goals are set
early on
• Build scalabilty goals into your
SDLC
• Tactical
• Testing tools

9. Mistake #2
Using SharePoint lists as an
OLTP database

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. 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. SharePoint 2013 Provider Hosted
• Custom Database
• ASP.NET development model
• Connect to SharePoint using CSOM
• Required security token and framework

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. Mistake #3
Iterating through SPList

15. Don’t loop through Lists
• Instead use a CAML Query
• SPQuery properties:
• Query
• RowLimit
• ViewFields

16. Demo

17. Mitigation
• Strategic
• Add volume testing to all stages of
SDLC
• Tactical
• Code reviews
• Education

18. Mistake #4
Forgetting about Caching

19. Types of Caching
• BLOB caching
• Page output cache profiles
• Object cache
• Anonymous search results cache
• Custom code: ASP.NET cache

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. 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. Mitigation
• Strategic
• Make sure caching is part of the
SDLC
• Tactical
• Evaluate different caching
mechanisms

23. Mistake #5
Failing to estimate and test
for concurrent user load

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. 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. 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. 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. Mistake #6
Failing to account for data
growth

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. 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. 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. Mistake #7
Not Leveraging Search

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. Mitigation
• Strategic
• Increase awareness
• Tactical
• POC some functionality leveraging
search
• Make sure to understand indexing
and volume time

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. 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. 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