top 7 mistakes

Download Top 7 mistakes

Post on 15-Jul-2015




1 download

Embed Size (px)


Building High Performance and Scalable SharePoint Applications

Top 7 Mistakes when Building Scalable SharePoint ApplicationsTalbott

Mistake #1 Conflating Performance and ScalabilityTerminologyPerformanceBehavior and response time for a single user or multiple users under loadScalabilityBehavior and response time for a growing number of users and volume under load

PerformanceA Lamborghini performs well

Ferrari is a high performance vehicle

ScalabilityA Greyhound bus performs even better than a Ferrari when transporting 100 passengers from Boston to San Francisco

https://www.greyhound.comExampleThe 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 dont use it simultaneously (still effectively single user)The application is launched and thousands of users start using it and concurrency issues ariseSolutionAdd load testing to your SDLC (software development lifecycle)The earlier the betterMany large Fortune 500 companies have a mandatory stage in their SDLC for volume testingAdding it into a continuous integration environment is even betterBetter catch it early than right before scheduled deployment to productionMitigationStrategicMake sure scalability goals are set early onBuild scalabilty goals into your SDLCTacticalTesting toolsMistake #2Using SharePoint lists as an OLTP databaseSolution ArchitectureSharePoint stores data in listsLists are abstractions that are physically represented as records in the content databaseIf you are building an application in SharePoint, consider the options in storing the data in its own databaseSQLDesign for the FutureOffice 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 neededSharePoint 2013 Provider HostedCustom DatabaseASP.NET development modelConnect to SharePoint using CSOMRequired security token and frameworkMitigationStrategicEducation on SharePoint Provider Hosteted AppsTacticalBuild POCsMake sure custom DBs are considered when laying out architectureMistake #3Iterating through SPListDont loop through ListsInstead use a CAML QuerySPQuery properties:QueryRowLimitViewFieldsDemoMitigationStrategicAdd volume testing to all stages of SDLCTacticalCode reviewsEducationMistake #4Forgetting about CachingTypes of CachingBLOB cachingPage output cache profilesObject cacheAnonymous search results cacheCustom code: ASP.NET cache

Caching ConsideratinsWhat can be cachedWhat is heavily usedWhat takes up the most timeHow long can you cache those itemsMulti-server Farm ConsiderationsIf you implement custom ASP.NET caching, and need to clear the cacheMake sure there if the same user hits another server it doesnt still have data cached

MitigationStrategicMake sure caching is part of the SDLCTacticalEvaluate different caching mechanismsMistake #5Failing to estimate and test for concurrent user loadEstimate User LoadDocument Most Common Use CasesWeight each Use Case in percentageDetermine Peak User CountRun load tests on use cases weighted by percentageWhen should load test be run?Answer: the earlier the betterWaterfall:Requirements, Design, Develop, Functional Testing, Load Testing (sometimes too late), ProductionAgile: build load test into continuous integrationTest CasesKnow BEFORE you start designing, even before you are laying out the solution architecture what a real world scenario will look like

Use casesNumber of usersVolume of dataMitigationStrategicMake load and scalability part of the vision or mission statement for each projectTacticalKeep a catalog of non-functional requirementsAdd this to the checklist so every project requires load estimatesMistake #6Failing to account for data growthVolume of DataApplication might perform just fine with one to ten Purchase Orders, but what happens when there are hundreds of thousands?Know your target volumeSimulate that volume using scriptsMake sure at every step of the way, volume is considered:envisioning, designing, implementing, testingEstimate Volume of DataAfter you design your solution estimate what the volume might look like after a yearLoad a years worth of dummy dataUse PowerShell or C# codeMake sure developer, testers, and pilot users have volume pre-loadedMitigationStrategicMake load and scalability part of the vision or mission statement for each projectTacticalKeep a catalog of non-functional requirementsAdd this to the checklist so every project requires load estimatesMistake #7Not Leveraging SearchSearch is very scalableVery fast response for indexed dataTune your crawls, best bets, managed propertiesNot fast for immediate feedbackNot right solution for all situationsCrawls can sometime take hours/daysMitigationStrategicIncrease awarenessTacticalPOC some functionality leveraging searchMake sure to understand indexing and volume timeFinal Tip:Know SharePoint LimitationsWeb Applications per farmSite Collections per Web AppSites per CollectionLists per SiteItems per ListSharePoint Limitations

ReviewPerformance vs ScalabiltySharePoint lists not always a good substitute for transactional databaseFor each item in SPList vs CAML QueryCaching (many flavors)Concurrent User LoadData volume and growthMake sure to leverage Search

ResourcesOffice Dev Patterns and Practices on GitHub: Bundle: