升藍 CRM 系統性能指標

系統性能指標

• 統一性：
  • 系統的架構、服務、模塊、數據接口進行統一合理規劃，提高系統的性能。
  深圳升藍 0755-88291051
• 穩定性：
  • 高穩定性，系統總體可用率>99.7%，數據庫應用可用率>=99.8%，WEB應用可用率>=99.8%。
  升藍深圳hi-blue.com
• 可靠性：
  • 在系統設計架構的設計方面，充分考慮了系統的可靠性要求，滿足企業級計算所需要的高度。
  H i b l u e 0 7 5 5 - 8 8 2 9 0 3 6 1
• 安全性：
  • 提供強管理機制和控制機制，具有日誌監控、事故監控和網絡安全保密等技術措施。
  升 藍 w w w . h i - b l u e . c o m
• 高速高效：
  • 系統在編程設計時大量使用調整緩存機制，減少了系統IO的負載，極大地加快了系統的運行速度。
  H i b l u e 0 7 5 5 - 8 8 2 9 1 0 5 2
• 易操作性：
  • 提供友好的用戶管理和使用界面，便於操作的維護。
  升 藍 : h i - b l u e . c o m
• 靜態數據指標：
  • 系統能對2000用戶數據、狀態、和應用進行管理。
  H i b l u e 0 7 5 5 - 8 8 2 9 1 0 5 1
• 動態數據指標：
  • 並發訪問用戶數量應達到200以上，允許1000用戶同時在線。
• 系統響應速度：
  • 頁面響應速度，在合理網絡和平台配置情況下，則訪問操作性界面操作的系統響應時間小於5秒，靜態頁面標準響應時間小於2秒，簡單查詢頁面小於3秒，複雜查詢頁面小於5秒。（實際上測試得到的響應時間通常在0.05~0.1秒之間）。

系統性能的優化

系統性能的優化

• 對於一個WEB應用系統，系統性能主要體現在服務器端的性能表現。服務器端又分為WEB和應用服務器，數據庫服務器。為滿足系統性能的要求，我們在服務營銷廣場的系統性能設計方面有以下考慮。

系統整體性能

• 系統的性能是受限於系統中各個環節的瓶頸的。因此在服務營銷廣場整體設計中，我們遵循的原則是盡可能的將系統架構中的各個部分保持獨立。即系統的前台表現層、應用邏輯層和數據層是獨立的。當某個環節出現瓶頸時可快速的解決。如Web前台訪問的瓶頸可以通過增加Web負載均衡服務器來實現。

數據庫性能設計

• 邏輯數據庫設計遵循的基本規範
  • 沒有重複的組或多值的列;
  • 每個非關鍵字段必須依賴於主關鍵字，不能依賴於一個組合式主關鍵字的某些組成部分;
  • 一個非關鍵字段不能依賴於另一個非關鍵字段。
• 生成物理數據庫
  • 與每個表列相關的數據類型應該反映數據所需的最小存儲空間，特別是對於被索引的列更是如此。比如能使用smallint類型就不要用integer類型，這樣索引字段可以被更快地讀取，而且可以在一個數據頁上放置更多的數據行，因而也就減少了I/O操作。
  • 把一個表放在某個物理設備上，再通過SQL Server的段把它的不分簇索引放在一個不同的物理設備上，這樣能提高性能。

數據庫編程性能設計

• 合理使用索引
  • 索引是數據庫中重要的數據結構，它的根本目的就是提高查詢效率。索引的使用要恰到好處，其使用原則如下：
  • 在經常進行連接，但是沒有指定為外鍵的列上建立索引，而不經常連接的字段則由優化器自動生成索引；在頻繁進行排序或分組（即進行group by或order by操作）的列上建立索引；在條件表達式中經常用到的不同值較多的列上建立索引，在不同值少的列上不要建立索引。比如在僱員表的「性別」列上只有「男」與「女」兩個不同值，因此就無必要建立索引。如果建立索引不但不會提高查詢效率，反而會嚴重降低更新速度。 如果待排序的列有多個，可以在這些列上建立復合索引。
• 避免或簡化排序
  • 盡量簡化或避免對大型表進行重複的排序。當能夠利用索引自動以適當的次序產生輸出時，優化器就避免了排序這個步驟。為了避免不必要的排序，就要正確地增建索引，合理地合併數據庫表。
  • 消除對大型表行數據的順序存取
  • 在嵌套查詢中，表的順序存取對查詢效率可能產生致命的影響。可以使用並集來避免順序存取。儘管也許在所有的檢查列上都有索引，但某些形式的where子句會強迫優化器使用順序存取。
• 避免相關子查詢
  • 如果一個列同時在主查詢和where子句中出現，很可能當主查詢中的列值改變之後，子查詢必須重新查詢一次。而且查詢嵌套層次越多，效率越低，因此應當盡量避免子查詢。如果子查詢不可避免，那麼要在子查詢中過濾掉盡可能多的行。
  • 避免困難的正規表達式
  • Mathes和Like關鍵字支持通配符匹配，但這種匹配特別耗時。做這類查詢時注意查詢語句的寫法是否合理。
• 使用臨時表加速查詢
  • 把表的一個子集進行排序並創建臨時表，有時能加速查詢。它有助於避免多重排序操作，而且在其他方面還能簡化優化器的工作。臨時表中的行要比主表中的行少，而且物理順序就是所要求的順序，減少了磁盤I/O，所以查詢工作量可以得到大幅減少。

.Net編程性能設計考慮

• 程序的優化是系統性能保證的主要
• 充分利用緩存技術
  • 緩存是常用的提高性能的技術，它將訪問頻率高的數據或構造成本高的數據保留在內存中。在 Web 應用程序的上下文中，緩存用於在 HTTP 請求間保留頁或數據，並在無需重新創建的情況下重新使用它們。
  • ASP.NET 有三種可由 Web 應用程序使用的緩存：
    • 輸出緩存，它緩存請求所生成的動態響應。
    • 片斷緩存，它緩存請求所生成的響應的各部分。
    • 數據緩存，它以編程方式緩存任意對象。
  • 應用程序以及生成的用戶頁面，根據實際需要設置輸出緩存；對於經常用到的用戶控件使用片斷緩存；對於系統配置信息使用數據緩存。
• 慎用ViewState
  • EnableViewState(頁面的視圖狀態)。如果無特殊要求設置為false。
  • 使用ViewState ，每個對象都必須先序列化到 ViewState 中，然後再通過回傳進行反序列化，因此使用 ViewState是有代價的。盡量減少使用對象，如果可能，盡量減少放入 ViewState 中的對象的數目。
  • 項目發佈的時候解除頁面的Debug狀態。
• 借助客戶端的力量
  • 盡量選擇html控件。能在客戶端實現的功能就在客戶端實現，減少服務器的壓力。數據控件選擇順序：Repeater、DataList、DataGrid

其他性能因素

• 系統上線前做嚴格的壓力測試
  • 只有在系統上線和每個新增應用上線前做好了嚴格的壓力測試，才能保證系統的性能是基本可控的。
• 盡可能採用靜態頁面
  • 對於內容基本固定，變動頻度極小而訪問量大的頁面，我們可以採用純靜態頁面。對於變動頻度相對小的頁面和應用，可以採用.NET輸出緩存的技術，避免頻繁的數據查詢和頁面重新編譯等。
• 減少大數據量運算
  • 如系統用戶行為的統計分析，數據量可能很大，可以定時在晚上系統負載小的時候進行，分析的結果保存供需要時訪問。避免負載高峰時做長時間的運算，影響整個系統的運行效率。
• 系統性能優化
  • 當系統出現性能問題時，檢查性能問題和系統性能的優化可以從以下幾個層面著手：
    • 系統級（包括系統的軟硬件配置）
    • 數據庫級（包括數據庫設計和編程）
    • 應用程序程序級（包括應用實現的設計和編碼）

使用高速緩存技術

• 系統的性能的最大瓶頸是系統的磁盤IO，使用高速緩存技術，減少磁盤IO的負載，可大幅度提高系統的性能。
• 在一些典型測試結果中，使用高速緩存的系統性能可以提高500倍。
• 保險業CRM系統的高速緩存有兩個方面的應用：
  • 編程高速緩存
    • 在應用程序中使用緩存。
  • 系統高速緩存
    • 系統高速緩存是一種內存映射技術，即將內存和磁盤映射起來，由系統的服務層建立硬盤的內存映像，應用程序在內存中訪問磁盤。