性能瓶頸??

性能瓶頸實際上就是一個軟體的性能缺陷

  那我們如何最通俗的理解“性能瓶頸”

  （1）硬體上的性能瓶頸

      主要指的是CPU、RAM方面的問題。

      例如，

      在進行軟體需求分析、概要設計時，確定了在資料庫伺服器上需要6個CPU、12G記憶體，

      但是在測試時，發現CPU的持續利用率超過95%，

      這時可以認為在硬體上出現了性能瓶頸。

  （2）應用軟體上的性能瓶頸

      一般指的是應用伺服器、WEB伺服器等應用軟體，還包括資料庫系統。

      例如，

      在WEBLogic平臺上配置了JDBC連接池的參數，最大連接數為50，最小連接數為5，增加量為10。

      在測試時發現，當負載增加時，現有的連接數不足，系統會動態生成10個新的連接數，這樣導致了交易處理的回應時間大大的增加。

      這時可以認為在應用軟體上出現了性能瓶頸。

  （3）應用程式上的性能瓶頸

    一般指的是開發人員新開發出來的應用程式。

    例如，

      用Java或者C開發出來的部署在應用伺服器上用於使用者交易請求處理的應用程式。

    例如，

      某個開發員開發了一個繳費處理常式，在測試時發現，

      這個繳費處理常式在處理用戶發過來的併發繳費請求時，

      只能連續處理，無法並行處理，

      導致繳費交易的處理回應時間非常長，

      這時可以認為在應用程式上出現了性能瓶頸。

  （4）作業系統上的性能瓶頸

      一般指的是Windows、Unix、Linux這些作業系統。

      例如，

        在windows系統中，虛擬記憶體設置的不合理，

        都指定為C驅提供虛擬記憶體，

        在測試時發現當出現實體記憶體不足時，

        虛擬記憶體的交換效果非常不理想，

        導致交易的回應時間大大增加。

        這時可以認為在作業系統上出現了性能瓶頸。

  （5）網路設備上的性能瓶頸

      一般指的是防火牆、動態負載等化器、交換機等設備。

      例如，

        在動態負載等化器上設置了動態分發負載的機制，

        當發現某個應用伺服器上的硬體資源已經到達極限時，

        動態負載等化器將後續的交易請求發送到其它負載較輕的應用伺服器上。

        在測試時發現，動態負載均衡機制沒有起到相應的作用，

        這時可以認為在網路設備上出現了性能瓶頸。