Performance Metrics(性能指標1)

Performance Metrics(性能指標)

在咱們開始旅行本書以前，我必須先了解本書的性能指標和但願優化後的結果，在第二章中，咱們探索更多的性能檢測工具和性能指標，但是，您得會使用這些工具和明白這些性能指標的意義。

      因爲業務場景的不一樣和操做方式的不一樣，應用程序的性能指標狀況也不一相同。有時，咱們的應用程序規定了重要的性能指標，如webserver須要承受數百萬用戶的併發請求而創建了服務集羣和系統均衡負載，以保證應用體系的架構可伸縮的，可是咱們看到無數的例子是應用程序從新設計之後，run壓力測試經過後在生產環境應用時確失敗了。

　　在咱們的經驗看來，幫組您瞭解系統的性能目標和環境限制並提升性能，咱們有在過去幾年中解決這些問題的列子：

　　咱們發現一個web服務器數據託管中心的嚴重的性能問題，測試工程師使用數據中心4mbps共享形成了延遲,他們不瞭解關鍵性能指標，他們浪費了不少時間在調試其實是完美運做的web服務器性能問題上，咱們能在提升性能並在富UI應用上進行調優，咱們從新調整了 CLR\GC的時間分配，優化了UI滯後。咱們爲了提升編譯效率，解決了微軟一個磁盤驅動程序缺陷。咱們經過優化wcf序列化機制，挺高了消息交換90%的時間，爲了提升可伸縮性，咱們經過優化應用程序之間的依賴關係大大減小了其啓動時間。

　　這些例子從低功耗的觸摸設備到高功耗的圖形處理器經過數據中心展現微妙的交互性特徵，在這一章中，咱們簡要的探究典型現代軟件的性能指標和目標，下一章中咱們將介紹軟件性能測量標準以及如何提升應用程序的性能。

Performance Goals(性能目標)

　　應用程序的性能目標取決於其所服務的領域和服務的生命週期，當咱們完成需求分析的時候，咱們應該有一個清晰的性能目標，咱們簡單的介紹幾個性能目標的指導方針，這些案例可能適用於您的應用軟件。

　　首先，請看下面這些沒有良好性能的例子：

• 當不少用戶同時訪問購物車時
• 用戶分配不合理的內存
• 單個服務器查詢很快，可是多個服務器查詢則負載至滿

 

　　開發人員通常過於主觀的解鎖性能目標會和團隊的其餘人員難以達成共識，業務分析師認爲100000個併發是合理的，而技術團隊知道可用的硬件沒法支持這個併發，開發人員能夠考慮500ms的延遲響應，而UI體驗專家則認爲這是不合理的，性能目標表示爲可量化的性能指標，良好的性能指標包括：

• web一面響應時間不該該超過300ms
• 購物車應該支持5000個併發
• 每一個用戶的session分配的內存不該該超過4kb
• 數據庫服務器的I/O不該該超過70%，在不超過10臺應用服務器訪問的狀況下響應時間不該該超過75ms。

　　

　　咱們簡單的列了一個性能目標的表格

 

 

　　當咱們明確性能目標之後，咱們的測試盒性能優化工做才能得以進行，在下一章中，咱們將討論如何創建測試環境和熟悉性能指標。