搞服務器性能時有感

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

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

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

帶寬瓶頸高併發

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

      服務器的帶寬要多大?測試

      帶寬 = 1k * 6000 = 6Mspa

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

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

   

    可是,在真正的測試用,也是用的阿里的性能測試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來算好了,不一樣機器不一樣狀況,只作參考!

相關文章
相關標籤/搜索