Top 3 Mistakes when Building Scalable SharePoint

Applications

Talbott CrowellThirdM.com

@talbott

http://www.freeimages.com/photo/858598

Mistake #1

Conflating Performance and Scalability

Terminology

PerformanceBehavior and response time for a single user or multiple users under load

ScalabilityBehavior and response time for a growing number of users and volume under load

PerformanceA Lamborghini performs well

ScalabilityA Greyhound bus performs even better than a Lamborghini when

transporting 100 passengers from Boston to San Francisco

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

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

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 cases2. Number of users3. Volume of data

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…

Mistake #2

Using SharePoint lists as an OLTP database

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

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

SharePoint 2013 Provider Hosted

•Custom Database

•ASP.NET development model

•Connect to SharePoint using CSOM

•Required security token and framework

Mistake #3

Not using CAML to fetch items in a list

Demo

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