文章來自: http://www.chinaemail.com.cn/server/xtfl/Exchange/201109/66466.htmlhtml
SharePoint是微軟歷史上銷售量增加最快的產品,其能夠存儲大量的文件。這意味着應用性能是成功部署SharePoint的一個關鍵因素。咱們在這裏列出了可以提升SharePoint服務器性能的十個步驟。前端
步驟1:分離用戶和數據庫信息算法
一個常見的誤區是與高速網絡鏈接的服務器有着充足的帶寬執行全部須要的操做。可是SharePoint在SQL設置了大量的請求———每一個需求一個頁面的請求會致使向數據庫發送大量的請求,更不要說服務、檢索和其它操做了。數據庫
爲了緩解用戶與數據庫信息間的衝突,前端服務器和SQL鏈接應當被分離,讓它們分別經過獨立的物理網絡或虛擬LAN。這須要在每個前端Web服務器上至少配置兩個獨立的網絡接口卡,經過設置靜態路由確保信息被路由至正確的接口卡。相同的設置或許也可以被應用至應用索引服務器。緩存
步驟2:分離檢索服務器
一個典型的中型服務器羣由一臺或多臺Web前端服務器、一臺專用索引或應用服務器和一臺獨立的SQL數據庫服務器。由索引服務器發起的搜索信息必須由負責傳遞用戶內容的相同服務器處理。爲了防止搜索和用戶信息衝突,額外的服務器或許應當被添加至服務器羣中,這臺服務器只用來服務搜索查詢(在更小的環境中,索引服務器或許應當具有這一功能)。服務器羣管理員應當對搜索服務進行配置以僅在這臺專用戶服務器上執行收集功能。在搜索操做中,這一配置可能會減小Web前端服務器信息70%。網絡
步驟3:調整SQL參數app
一個避免麻煩的便捷方法是在獨立的物理磁盤(或是邏輯單元符號)上設置一個大型SharePoint數據庫。這意味着有一套搜索數據庫磁盤,一套臨時數據庫磁盤和內容數據庫磁盤。還須要對獨立的日誌文件(*.ldf)進行額外考慮。儘管這些不會此發與其它文件相同級別的I/O,它們在備份和恢復中扮演了一個主要的角色,它們會讓主數據庫文件大小翻上數倍。工具
另外一個方法是前攝性的管理單個數據庫的尺寸和增加。默認狀態下,SQL會讓數據庫文件以很小的規模遞增,大約以每次1MB或是以數據庫大小的固定百分比爲限(一般是10%)。這些設置致使SQL在反覆的形成數據庫浪費,在數據庫增大的同時妨礙了其它數據的寫入。一個備選方案是若是空間足夠大能夠從新將數據庫設置爲推薦的最大值(100GB),將自動增加設置爲一個固定值(如10MB或20MB)佈局
步驟4:整理數據庫索引碎片
SQL服務器維持對存儲在多個數據庫中數據的索引,以改善查詢效率和讀取操做。就像文件存儲在硬盤中同樣,這些索引也會碎片化。按期進行維護操做十分重要。因爲這種維護屬於資源密集性操做,所以在按期執行這類操做時應當特別注意,許多時候,會影響到數據寫入或讀取。
步驟5:在多內容數據庫分散用戶數據
大多數SharePoint數據被存儲在列表中:任務、通知、文件庫、問題、圖片庫等等。大量的這種數據實際上被存儲在與站點集合相聯繫的內容數據庫的單一表單上。這與在SharePoint層內有多少站點和子站點被建立沒有關係,每個站點集合僅與一個內容數據庫相聯。這意味着一個帶有數千個子站點的站點集合存儲了大量的用戶數據。這些用戶數據來自於SQL單一表單上的每個站點所存儲的每一份列表。
因爲SQL必須在一個潛在的很是龐大的數據組中遞歸執行查詢,這會致使延時。減小工做負載的一個辦法是讓站點集合映射至內容數據庫。
步驟6:縮小頁面尺寸
對於經過LAN與入口相聯的SharePoint用戶來講,管理內容和尋找資源很容易,可是對於經過低速WAN的遠程用戶來講,帶有大量元素的SharePoint頁面是一個性能殺手。
若是你有許多遠程用戶,你須要啓動一個小型母版頁,就像字面意思同樣,去除不須要的元素,容許設計者啓動一個只包含有基本功能的乾淨的頁面。
其次,大多數SharePoint頁面都包含了支持文件連接,包括JavaScript、樣式表,這些都須要額外的時間進行檢索和執行。
步驟7:配置IIS壓縮
SharePoint內容由兩個主要來源組成———在SharePoint根目錄下存儲的靜態文件(C:\ProgramFiles\CommonFiles\MicrosoftShared2007版爲\12和2010版爲\14)和存儲在內容中的動態數據。在運行時SharePoint從這兩個來源中合併頁面而後將它們傳輸至內一個HTTP上以響應請求者。互聯網信息服務器(IIS)版本6和7都包含了多種機制可在將頁面傳輸至網絡上以前減小HTTP響應的有效負載。調整這些設置可以減小傳輸給客戶的數據大小,縮短載入時間,加快網頁渲染。
IIS壓縮設置可能經過將基礎值0(不壓縮)修改成最大值10(充分壓縮)。這一設置的調整決定着IIS執行壓縮算法的程度。
步驟8:利用緩存
用戶請求的多數內容都可以被緩存在內存上,包括表單項目、文件、查詢結果等等。站點管理員可以配置他們本身的緩存文件以知足不一樣的用戶需求。好比,匿名用戶可以被指定一套緩存策略,受權用戶可以被指定另外一套策略,與普通讀者相比,內容編輯能夠瀏覽最新的內容變化。經過頁面類型也能夠配置緩存文件,因此公佈頁面和佈局頁面表現是不一樣的,管理員有權選擇詳細設定服務器和客戶端上的緩存策略
步驟9:管理頁面定製
SharePointDesigner是一個對管理員和高級用戶極爲有用的工具,可是頁面定製將妨礙整體性能。當進行定製時,整個頁面內容,包括標記和內聯代碼都會被存儲在數據庫內容,每當頁面被請求時都必須被取回。雖然對逐頁母板頁影響不大,可是在有着數百甚至數千頁面時,這種對數據庫反覆讀取將嚴重影響到性能。
爲了防止這一問題,管理員應當執行一個限制頁面定製,只有當絕對須要時才能夠進行定製的規定。
步驟10:限制導航深度
全部門戶網站的一個最重要設計元素是在每一個網頁的頂部都設置了全局下拉彈出式菜單。這看起來是一個導航的便捷方法,可是這個設計過深,在最初的幾級菜單完全失去以前導航功能已經變得極爲混亂了。更爲糟糕的是,讀取全部的數據以填充導航菜單在分級很深的網站上極爲佔用資源。
SharePoint設計者能夠經過修改母版頁內容的導航控制參數來定製每一個導航菜單的深度和級別管理員應當將導航深度限制在一個可控級別以內以防止影響性能。