The document discusses 3 common mistakes made when building scalable SharePoint applications: 1. Conflating performance and scalability and not conducting proper load testing. Performance is for a single user while scalability is for growing number of users. Load testing should be part of development process. 2. Using SharePoint lists as an operational database which is not best practice. Lists are meant for abstraction, not large transactional databases. Consider a custom SQL database instead. 3. Not using CAML (Common Application Markup Language) to efficiently fetch list items which can impact performance and scalability. The document provides recommendations to avoid these mistakes like designing for future growth and volume from the start.

1. Top 3 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

5. Scalability
A Greyhound bus performs even better than a Lamborghini when
transporting 100 passengers from Boston to San Francisco

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

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

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

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

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

13. SharePoint 2013 Provider Hosted
•Custom Database
•ASP.NET development model
•Connect to SharePoint using CSOM
•Required security token and framework

14. Mistake #3
Not using CAML to fetch
items in a list

15. Demo

16. Resources
• Bit.ly Bundle:
• https://bitly.com/bundles/talbott/2
• Blog:
• http://talbottcrowell.wordpress.com/
• Twitter:
• https://twitter.com/talbott
• Office Dev Patterns and Practices on GitHub:
• http://bit.ly/o365pnp