SharePoint諮詢師之路:設計以前的那些事一:容量

提示：本系列只是一個學習筆記系列，大部份內容均可以從微軟官方網站找到，本人只是按照本身的學習路徑來學習和呈現這些知識。

諮詢師更多的時候是解決方案提供者，那麼他們如何可以提供有效的SharePoint解決方案呢？他們作出解決方案的依據是哪些呢？這就是咱們須要瞭解的設計以前的那些事。

它一般包括：

• 容量管理
• 規模
• 體系結構
• 其它

容量規劃只是管理週期的一部分。它是最初的一組活動，這組活動使得設計架構師堅信有個初始的體系結構最適合SharePoint Server的部署。容量管理模型還包括可幫助你驗證和優化初始體系結構的其餘步驟，並提供一個反饋循環，可用於從新規劃和優化生產環境，直到該環境能夠經過所選的最佳硬件、拓撲和配置知足設計目標。

 

術語表

首先來了解下SharePiont Server容量管理文檔中使用的專業術語：

• RPS：每秒請求數。服務器場或服務器每秒接收的請求數。這是測量服務器和服務器場負載經常使用方法。服務器場處理的請求數大於頁面加載和最終用戶交互數。這是由於每一個頁面可能包含若干個組件，二頁面加載時，每一個組件又建立多個請求。
• 高峯期：服務器場中的負載在一天內處於最大值的時間。
• 高峯負載：服務器場中的平均最大每日負載，以PRS度量
• 瞬時負載峯值：在一般高峯期以外的瞬態負載峯值。用戶流量意外增長、或者因爲管理操做致使服務器場吞吐量減小或者此類因素，都可能引發瞬時負載峯值。
• 向上擴展：向服務器中添加處理器或者內存資源
• 向外擴展：向服務器場中添加更多服務器

 

性能的四個基本要素

在肯定解決方案規模時，容量管理關注一下四個主要方面：

• 延遲:  在容量管理中，延遲被定義爲用戶啓動操做與將最後一個字節傳送給客戶端應用程序或者web瀏覽器之間的持續時間
• 吞吐量：吞吐量定義爲服務器或者服務器場能夠處理的併發請求書
• 數據規模：數據規模定義爲系統能夠託管的內容大小和數據集。內容數據庫的結構和分佈對於系統處理請求的時間（延遲）和系統能夠處理的併發數（吞吐量）有顯著影響
• 可靠性：可靠性用於衡量系統在一段時間內知足所設定的延遲和吞吐量目標的能力。

 

容量管理的目標

延遲

延遲，也成爲最終用戶感知的延遲，它只要包括三個部分：

• 服務器接收和處理請求所用時間
• 經過網絡傳輸請求和服務器響應所用的時間
• 在客戶端應用程序中顯示相應所用的時間。

延遲的只要因素：

• 未優化的功能，服務或者配置參數可能會單個請求的處理，並影響遠程和本地客戶端的延遲。
• 有些網頁會對服務器生成沒必要要的請求來下載所需的數據和資源。而優化包括下載最少數量的資源來提取頁面，減小圖像大小，在容許匿名訪問的文件中存儲靜態資源，異步請求服務器資源等。
• 經過網絡傳輸大量數據會增長延遲並下降吞吐量。例如頁面的圖像和其餘二進制對象應儘量的使用壓縮格式（PNG，JPG）而不是位圖。
• 未針對二次訪問頁面加載進行優化的網頁。因爲有些資源緩存在客戶端，而瀏覽器只下載未緩存的動態內容。
• 包含未優化的自定義JavaScript代碼的網頁，應首選腳本而不是內聯的Javascript

 

吞吐量

吞吐量有服務器場在單位時間內能夠處理的請求數來描述，一般根據組織的規模及其使用特徵來衡量系統預計能夠維持的操做的規模。

地吞吐量狀況的一些常見示例包括：

• 硬件資源不足當服務器才收到的請求多餘它能夠處理的請求時，有些請求會排入隊列，這樣累積的結果就是推遲每一個後續請求的處理，知道請求減小到能夠清除隊列爲止，優化服務器場能夠維持較高的吞吐量的一些示例：
• 確保服務器中的處理器未過分使用，例如高峯期或者瞬時負載峯值期間的CPU使用率持續超過80%，則能夠添加更多的服務器或將服務從新分配給其餘場服務器。
• 確保應用程序服務器和web服務器上有足夠的內存來包含完整緩存。這有助於避免調用數據庫，以便針對爲緩存內容的請求提供服務。
• 確保數據庫沒有瓶頸。若是總能夠磁盤IOPS不足以支持高峯請求，則須要添加更多的磁盤或者將數據庫從新分配給利用率地下的磁盤。
• 若是向現有計算機中添加資源仍沒法解決吞吐量的問題，則能夠添加服務器並將受影響的功能和服務從新分配給新的服務器。
• 未經優化的自定義網頁  在生產環境中向經常使用頁面添加自動以代碼一般會引發吞吐量問題。自定義代碼可能會生產到數據庫服務器的其餘往返行程或服務於請求的web服務器。自定義不常使用的頁面可能不會顯著影響吞吐量，可是若是天天請求上千次，即便進行良好優化的代碼也會下降服務器場的吞吐量。

SharePoint 2013 管理員可使用開發人員儀表板來識別須要優化的自定義代碼。經常使用的優化示例：

• 最大限度減小web服務器請求和SQL查詢的數量
• 在前往數據庫服務器的每一個行程中提取所需最少的數據，同事最大限度的減小所需往返行程。
• 避免向經常使用頁面添加自定義代碼
• 在檢索經篩選的數據量時使用索引

• 不受信任的解決方案在Bin文件中中部署自定義代碼會致使服務器性能變慢。每次請求包含不受信任代碼的頁面時，SharePoint Server 2013 都必須進行安全檢查，而後才能加載頁面。除非有特殊緣由，須要部署不受信任的代碼，不然應該GAC中安裝自定義程序集，以免沒必要要的安全檢查。

 

數據規模

數據規模是服務器或者服務器場在知足延遲和吞吐量目標的同時能夠存儲的數據量。一般，服務器場中的數據量越大，對整體的吞吐量和用戶體驗的影響越大。用於跨磁盤和數據庫服務器分佈數據的方式也會影響服務器場延遲和吞吐量。

數據庫大小，數據庫的體系結構和足夠的數據庫服務器硬件對於最佳的數據庫解決方案都相當重要。在理想的部署中，根據限制指導肯定內容數據庫大小並跨物理磁盤分佈這些數據庫。

一下是針對數據庫和存儲性能優化服務器場的示例：

• 確保數據庫正確分佈在數據庫服務器上。而且數據庫服務器資源足以支持數據的數量和分佈
• 將數據庫卷分隔爲惟一的物理磁盤主軸構成的惟一邏輯單元，使其具備短尋道時間和適當的RAID配置的多個磁盤來知足數據庫服務器的存儲需求
• 若是數據庫包含許多二進制大型對象（BLOB），則可以使用遠程BLOB存儲（RBS）。 RBS能夠提供如下好處：
• BLOG數據能夠存儲在配置用於處理簡單存儲的較爲便宜的存儲設備
• 對BLOB存儲的管理由專門設計用於處理BLOB數據系統進行控制
• 數據庫服務器資源能夠釋放用於數據庫操做

 

可靠性

可靠性是對服務器場在一段時間內知足設定的延遲，吞吐量和數據庫絨裏目標能力的綜合度量。

有關如何維持更可靠系統的一些實例：

• 在非高峯期間計劃資源密集型計時器做業和管理任務
• 在現有場服務器中向上擴展硬件，或者經過添加web服務器，應用程序服務器或者數據庫服務器進行向外擴展。
• 將資源密集型服務和功能分配給專用的服務器。還可使用硬件負載平衡器將特定於功能的流量引至於特定的功能或者服務的web服務器

如何進行容量管理和容量規劃

咱們採用微軟推薦的標準模型來進行規劃：

步驟1：建模建模是決定但願環境支持的關鍵解決方案並創建全部重要的指標和參數的過程。建模的輸出應該是設計環境所須要的所有關鍵數據的列表

• 工做負載和數據集
• 設置服務場的性能和可靠性目標
• SharePoint Server 2013 IIS 日誌

步驟2：設計從步驟1收集數據後，即可設計你的服務器場。輸出爲詳細的數據體系結構以及物理和邏輯拓撲

• 肯定起點體系結構
• 選擇硬件

步驟3：試驗，測試和優化根據設計，部署用於測試工做負載和預期使用特徵的實驗環境。對於現有服務器場，建議在對基礎結構作主要更改時進行測試，但爲了維護性能目標，可能須要根據監視結構按期執行優化。此階段的輸出是：根據目標對測試結果的分析，以及可以實現設定的性能和容量目標的優化體系結構

• 試驗部署試驗環境
• 測試針對延遲和吞吐量目標進行測試
• 優化收集測試結構並對服務器場資源或拓撲進行任何所需的更改

步驟4：部署如何實現服務器場或者向現有服務器場部署更改。

步驟5：監視和維護介紹如何設置監視，以及如何預測和識別瓶頸並執行常規的維護和緩瓶頸操做

下一篇:規模