搞服務器性能時有感

這段時間一直在搞性能，由於要應對高併發的狀況，每秒有2000用戶的併發。

在這個併發裏面，到底有多少請求的，其實要按照用戶請求的頁面來平均一下，若是說平均每一個頁面要請求3個接口，那麼2000用戶併發的話，請求數就是：2000 * 3 = 6000；

服務器要在一秒內解決這6000個併發，換而言之，就是TPS爲6000，這時候必須先假設前提條件：

帶寬瓶頸

一、假設服務器是8核的，計算能力穩定，沒有數據庫請求的延遲狀況。那麼瓶頸在於帶寬。若是你請求的接口返回的報文（response）是1k，那麼

      服務器的帶寬要多大？

      帶寬 = 1k * 6000 = 6M

      這個帶寬理論上就是你公網流出的帶寬大小。可是，我在阿里的ECS裏買的帶寬是10M。據其文檔所說

      很天然地認爲，6000個TPS一點問題都沒有，固然這是一種很理想的狀態下。然而現實很骨感，你公網流出的帶寬可能都是顯示10M

   

    可是，在真正的測試用，也是用的阿里的性能測試TPS，峯值帶寬得出的結果是

     

    這是怎麼回事？看阿里的文檔

   

       那實際的上下載速度多大呢，嗯……它實際就是符合 128KB x 帶寬 = 實際上下載速度。因此，10M的帶寬，實際流出（即服務器自己的上傳速度）是 128KB/s X 10 = 1.2M。這樣就合情合理了。因此，你TPS爲6000，理論上來說須要多大的帶寬呢？

      實際ECS須要的帶寬是：6000 * 1KB / 128KB = 46.875M。

      這是在CPU無瓶頸狀況下，支持6000TPS的帶寬須要 46.875M。

 

CPU瓶頸

二、假設帶寬無瓶頸的狀況下，8核CPU每秒能處理的TPS的量是多大呢？實際上是不少因素有影響的，不能單獨的只考慮CPU。那麼以個人實際ECS來算好了，不一樣機器不一樣狀況，只作參考！