8257 interfacing 2 in microprocessor for btech students
HSPS 2015 - SharePoint Performance Santiy Checks
1. 0
Key Performance Sanity Checks
Andreas Grabner (@grabnerandi)
http://dynatrace.com/en/sharepoint
2. 1
Welcome to SharePoint Saturday Houston
• Please turn off all electronic devices or set them to vibrate
• If you must take a phone call, please do so in the hall so as not
to disturb others
• Special thanks to our Title Sponsor, ProSymmetry
Thank you for being a part of the
5th Annual SharePoint Saturday
for the greater Houston area!
4. 3
Information
• Speaker presentation slides should be available
from the SPSHOU website within a week or so
• The Houston SharePoint User Group will be
having it’s next meeting Wednesday April 15th.
Please join us at www.h-spug.org
7. 6
What are these 4 Ideas?
1. 7 Steps to check SharePoint Health
2. Avoid common Deployment Mistakes
3. Analyze SharePoint Usage
4. Which Pages are Slow and Why?
Bonus: Real Life Troubleshooting Example
8. 7
7 Step SharePoint Health Check
#1: End User Health #3: System Health#2: Site Health
#4: IIS Health #5: AppPool Health #6: SQL & Service Health
#7: Web Parts
9. 8
Check #1: End User Health
#1: Geo Location
#2: User
Environment
#3: Errors
10. 9
Check #2: Site Health
#1: Load #2: Failures
#3:
Performance
#4:
Infrastructure
#5: End User
Index
11. 10
Check #3: System Host Health
#1: CPU & Memory
#3: Process Check: Need to
RE-DEPLOY?
#2: I/O: Static & Logs
17. 16
Who’s talking with whom?
How many Web Sites are
actually running?
How many requests make it
to SharePoint’s AppPool?
Do we call any external
services
Is our SQL Server
overloaded?
18. 17
Any Deployment Mistakes? HTTP 5xx, 4xx?
Which errors are thrown by which page?
Which Errors impact
how many users?
20. 19
Connectivity Issues between Services?
Watch out for Connection
Exceptions!
This is the page that
tries to connect to
that backend service!
Root Cause:
Configuration Issue
27. 26
How are people navigating through SharePoint?
Which browsers do
people use?
Where are they from?
Which Office?
How do they navigate
through the site?
How fast/slow are
these pages for
them?
Maybe impacted by
bad network
connectivity?
28. 27
Which Lists/Views are Used?
How often used? How fast/slow? Time spent in SQL Server?
Same information
interesting per View
High Failure Rate?
34. 33
Many reasons for bad performance
• Frontend
– Overloaded and complex Pages
– Too much JavaScript slows down older browsers
– Bad content caching
• Backend
– Bad/Too Much Database Access
– Bad Coding of custom code
– Overhead due to configuration issues and resulting logs/exceptions
– High Memory Consumption
– Wrong Deployment Configurations (e.g: worker threads, …)
38. 37
Database Impact: Whom to blame?
• Overloaded Pages with too many Web Parts
• Badly implemented custom web parts
• 3rd party WebParts or Controls
39. 38
Bad Coding of Custom Web Parts - #1
ALL List Items are retrieved from the Database
DO NOT
int noOfItems = SPContext.Current.List.Items.Count;
Item Count is kept redundant in the AllUserData table and also kept in memory
DO
int noOfItems = SPContext.Current.List.ItemCount;
40. 39
Bad Coding of Custom Web Parts - #2
DO NOT
for (int itemIx=0;itemIx< SPContext.Current.List.Items.Count;itemIx++) {
SPListItem listItem = SPContext.Current.List.Items[itemIx];
// do something ...
}
Every access to Count and Items Property queries the whole SharePoint list
We end up with 202 SQL Executions with a total exec time of > 1s
41. 40
Good Coding of Custom Web Parts - #2
DO
SPListItemCollection items = SPContext.Current.List.Items;
foreach (SPListItem listItem in items) {
// do something ...
}
Only first access to the collection queries the data
42. 41
Telerik Grid Control Going Wild
#1: Data Driven Problem
Depending on the user input
on that request we see up to
493! SQL Calls per request
Root Cause: Every Grid Cell
executed a new SQL
#2: Statements not prepared
None of these executions has
been prepared
47. 46
Frustrated User report bad Response Times
Frustrated User
Slow Page Load caused by Browser JS Time
Slow Page Load caused by Server-Side Processing
48. 47
Really slow page
6.8s to deliver Default.aspx page
Involved Web Parts
Most of the Time spent
In waiting
50. 49
First Remote Call is Very Slow
Web Service call by ContentEditorWebPart
HttpWebRequests uses ServicePoint internally
First Web Serivce Requests takes 5.8s to return
51. 50
Thread Limit lets all other Threads wait!
We have 10 parallel calls in our background threads
The other background threads spend their time
“waiting” in the ServicePoint
53. 52
Key Points to Take Home
#1: End User Health: Happy or
Frustrated? Desktop or Mobile?
#3: System Health: CPU, Memory,
Process Distribution, …
#2: Site Health: Any Errors? Any
Performance Issues?
#4: IIS Health: Bandwidth?
Threads? HTTP 4xx, 5xx?
#5: AppPool Health: Memory,
CPU, GC, Exceptions, Logs …
#6: SQL & Service Health: # Roundtrips,
Data Amount, CPU, Memory, I/O
#7: Web Parts: 3rd Party &
Custom. Bad Coding and Bad
Deployments lead to crashes
54. 53
More Links for You
• Tools: http://dynatrace.com/en/sharepoint
• More Stories: http://blog.dynatrace.com/
• YouTube Tutorials: http://bit.ly/dttutorials
• Follow Me: @grabnerandi
• Contact Me: agrabner@dynatrace.com
55. 54
Please Leave Feedback During Q&A
Please submit feedback by
going to
http://whatsyouranswer.com?
S201547151810
or by scanning the QR code to
the right
Hinweis der Redaktion
And that’s my professional background
#1: End User Health: Happy or Frustrated? Desktop or Mobile?
#2: Site Health: Any Errors? Any Performance Issues?
#3: System Health: CPU, Memory, Process Distribution, …
#4: IIS Health: Bandwidth? Threads? HTTP 4xx, 5xx?
#5: AppPool Health: Memory, CPU, GC, Exceptions, Logs …
#6: SQL & Service Health: # Roundtrips, Data Amount, CPU, Memory, I/O
#7: Web Parts: 3rd Party & Custom. Bad Coding and Bad Deployments lead to crashes
#1: Geo Location: Where from is SharePoint Accessed? Which Offices? Which Remote Locations?
#2: User Environment: Is everyone using IE? How many use Mobile Devices? Bandwidth Issues?
#3: Errors: Bad URLs? Bad JavaScript? Missing files?
#1: Load: Which sites are used?
#2: Failures: Any functional issues?
#3: Performance: Meeting our SLAs?
#4: Infrastructure: Servers Healthy?
#5: End User Index: Happy users?
Don’t just look at Windows OS Metrics such as CPU, Memory, Disk and Network Utilization
Monitor individual SharePoint AppPool worker processes (w3wp.exe) to identify sites that overload this server
#1: CPU & Memory: Background Jobs Running? What else is consuming it?
#2: I/O: Too much logging? Serving too many static files? Data Sync Jobs?
#3: Process Check: Which processes are consuming these resources? Need to RE-DEPLOY processes?