building high performance and scalable share point applications
DESCRIPTION
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.TRANSCRIPT
Building High Performance and Scalable SharePoint Applications
Talbott CrowellThirdM.com
@talbott
http://www.freeimages.com/photo/858598
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
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
• A Lamborghini performs well
Performance
ScalabilityA Greyhound bus performs even better than a Lamborghini when
transporting 100 passengers from Boston to San Francisco
Software Development Life Cycle
• Waterfall• Agile• Combination
What's missing from this graphic?
• Testing!– Functional Testing– Performance Testing– Scalability Testing
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
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
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
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
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
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
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?
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
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
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
SHAREPOINT 2013 PROVIDER HOSTED
•Custom Database•ASP.NET development model•Connect to SharePoint using CSOM•Required security token and framework
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
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
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
INSTRUMENTATION
• Leverage ULS logging• Implement your own logging• Incorporate a third party logging or instrumentation product or framework
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
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
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
REVIEW
•What is faster, a lambo or a bus?•When should you be thinking about performance and scalability?
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
Was made possible by the generous support of the
following sponsors…
And by your participation… Thank you!
Be sure to fill out your eval form & turn in at the
end of the day for a ticket to the BIG raffle!
Join us for the raffle & SharePint following the last session