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.

1. Building High Performance and
Scalable SharePoint Applications
Talbott Crowell
ThirdM.com
@talbott
http://www.freeimages.com/photo/858598

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 SharePoint’s
Strengths
• What to Avoid
• Developer Dashboard
• Instrumentation
• Phases of SDLC

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. Software Development Life Cycle
• Waterfall
• Agile
• Combination
What's missing from this graphic?
• Testing!
– Functional Testing
– Performance Testing
– Scalability Testing

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

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

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
http://www.freeimages.com/photo/1391608

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…
http://www.freeimages.com/photo/1209714

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
• http://bit.ly/limits2013
http://www.freeimages.com/photo/790725

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?

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

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

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

17. SHAREPOINT 2013
PROVIDER HOSTED
•Custom Database
• ASP.NET development model
• Connect to SharePoint using
CSOM
• Required security token and
framework

18. Know SharePoint’s 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?
http://www.freeimages.com/photo/1369150

19. AVOID
• Looping though items
• Use targeted CAML queries instead with
SPQuery, SPSiteDataQuery, etc..
• Using Web Parts when they aren’t 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

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
• http://bit.ly/devdash

21. INSTRUMENTATION
• Leverage ULS logging
• Implement your own logging
• Incorporate a third party logging or
instrumentation product or framework

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 aren’t sure of
• Develop
• Build out the system
• Use tools like developer dashboard

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 http://bit.ly/vsload

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

25. REVIEW
• What is faster, a lambo or a bus?
• When should you be thinking
about performance and
scalability?

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

27. Was made possible by the generous
support of the following sponsors…
And by your participation… Thank you!

28. Join us for the raffle & SharePint
following the last session
Be sure to fill out your eval
form & turn in at the end of the
day for a ticket to the BIG
raffle!