Ep   share point top performance killers and best practices draft.v4
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Ep share point top performance killers and best practices draft.v4

  • 622 views
Uploaded on

Speed as perceived by the end user is driven by multiple factors, including how fast results are returned and how long it takes a browser to display the content

Speed as perceived by the end user is driven by multiple factors, including how fast results are returned and how long it takes a browser to display the content

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
622
On Slideshare
621
From Embeds
1
Number of Embeds
1

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 1

http://www.linkedin.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. SharePoint Top Performance Killers & Best Practices
    Ivan Sanders
    SharePoint ArchitectDimension Solutions inc.
    ivan@dimension-si.com
  • 2. Agenda
    Top Performance Killers
    Best Practices
  • 3. Speed as perceived by the end user is driven by multiple factors, including how fast results are returned and how long it takes a browser to display the content
  • 4. Top SharePoint Performance Killers
    Search
    Search uses SQL in a very I/O intensive fashion. It is sensitive to I/O latencies on the TempDB and the Query and Crawl file groups. One of the more difficult and time consuming jobs for a Search Administrator is to schedule the Crawls so they are not over lapping while keeping Search results fresh
    Indexing/Crawling
    Crawling and indexing a large volume of information, documents, and Web pages requires a large amount of computer processing. The crawl process also consumes network and other resources. The SharePoint environment must be configured properly and monitored, to ensure that the crawling and indexing process does not adversely affect the service available to users. For example, content is usually crawled and indexed during off-peak hours when servers are underused in order to maintain peak-hour services for users.
  • 5. Top SharePoint Performance Killers
    Profile Import
    Profile imports are used with NGES to sync your AD user details to provide access to your feed subscriptions and with SharePoint to sync your AD user details with your SharePoint User Profile
    Large List Operations
    Having large lists by itself is not necessarily a performance issue. When SharePoint Server renders the many items in those lists, that can cause spikes in render times and database blocking. One way to mitigate large lists is to use subfolders and create a hierarchical structure where each folder or subfolder has no more than 3,000 items. Identify large lists and work with the owners of the sites and lists to archive items or pursue other mitigation strategies
    Heavy User Operation List Import/Write
    Another scenario of users having power they don’t realize they have.  Importing large lists using excel or synchronizing an access db. In SQL there’s little difference between these types of user operations. 
    Backup (SQL & Tape)
    Serious CPU and write disk I/O performance hit. SQL Litespeed or SQL 2008 backup with compression all help to lessen the performance hit.
  • 6. Database Best Practices
    Optimize TempDb, Content, & SSP Dbs
    Creating secondary files for each db
    Move transaction logs to a separate unique Volumes
    Move data in primary file so that all files arte the same size
    Fragmentation
    occurs quickly with Dbs and Indexes that are constantly updated or in use. There are 2 types of Fragmentation that will cause SQL to slow down:
    File System
    Db Index/Statistics
    Monitoring
    Weekly reports to confirm trending on wait & performance stats
    DB Fill factor
    When an index is created or rebuilt, the fill factor value determines the percentage of space on each leaf level page to be filled with data, therefore reserving a percentage of free space for future growth. Based on past performance and index expansion rates, Microsoft has found the fill factor should be 70 percent on all content databases.
    Storage
    Allocate adequate storage for versioning and the recycle bin, and Defrag SQL will perform poorly. When designing the environment, CA should consider business needs, such as versioning, and ensure that adequate disk space and I/O are available to accommodate them and leave space to perform defragmentation
  • 7. VM Best Practices
    Web Front End (WFE) servers can be virtualized
    Query Server(s) can be virtualized
    Index Server should DEFINITELY NOT be virtualized
    SQL Server should NOT be virtualized
    Allocate RAW LUNs for the high performance volumes
    In the absence of RAW storage volumes, you should pre-allocate the storage space
  • 8. SharePoint Best Practices
    Tune the content of all crawls
    NGES, Coveo, SharePoint, and DocAve all crawl content. Tune the applications to reduce overlap.
    This is one of the most time consuming jobs of a SharePoint administrator
    • Use Dedicated WFE for crawling
    • 9. Remove the Central Administration server from NLB rotation since it is also indexing
    Optimize web Design
    Limit the Page Load size
    Maximize performance on Webparts displaying data
    Cleanup HTTP response codes of 300 and up (* excluding 304 & 401)
    Minimize HTTP Requests
    Plan and Enforce Site & Content Sizes
    Monitor Content and perform Cleanup
    Recycle App Pools
    For each WebSite on Each WFE at different times
    Periodically run Best Practice Analyzer BPA,
    Trends should be transparent
  • 10. Network Best Practices
    Load Balancing: Implement Caching to minimize traffic to database and application services.
    Secure Sockets Layer: Use hardware enabled services instead of software services.
    Implement WAN Acceleration anytime you are geographically dispersed across continents or where network latency must be mitigated.
    Dedicated Network Interface Cards: NIC to SQL, Dedicated NIC to Load Balancer. Avoid Shared IO.
  • 11. All other things being equal, more usage, as measured by number of page views & searches reflects more satisfied users.
  • 12. Q & A
  • 13. Most Common WaitsParallelism
    CXPACKET
    Direct result of inefficient parallel processing
    Occurs when 1 or more threads are waiting on another thread to finish before they can proceed
    Hyper-Threading can add to the problem
    Consider adjusting MAXDOP (at Server or Query Level)
  • 14. Most Common WaitsLocking
    LCK_M_xx
    LCK_M_SCH_xx
    Results from Locking & Blocking
    Long running transactions
    Improper or lack of indexes
    Poorly configured or underpowered hardware
  • 15. Most Common WaitsNetwork
    ASYNC_NETWORKIO
    Indicates that the client is not absorbing the data as fast as SQL Server can send it
    This may be related to problems with the Network itself
    But more likely it is the client that is to blame
  • 16. Most Common WaitsI/O
    PAGEIOLATCH_xx
    IO_COMPLETION
    WRITELOG
    Indicates slowness reading or writing data to physical disk
    These are definite signs that you have a problem with your storage subsystem or drivers
    WRITELOG waits should be kept as low as possible
  • 17. Most Common WaitsLatches
    PAGELATCH_xx
    Not related to physical IO
    Can indicate contention for internal resources other than the Buffer Pool
    PAGELATCH_UP typically indicates contention in Tempdb
    Heaps and LOB’s can cause latching
    Heavy Inserts onto the same pages
    Page splits