1. 程式人生 > >怎麼算我的應用需要多少寬頻來支撐,需要多少臺電腦,高併發級別簡述

怎麼算我的應用需要多少寬頻來支撐,需要多少臺電腦,高併發級別簡述

術語說明:
QPS = req/sec = 請求數/秒

QPS: 每秒鐘處理完請求的次數;注意這裡是處理完。具體是指發出請求到伺服器處理完成功返回結果。可以理解在server中有個counter,每處理一個請求加1,1秒後counter=QPS。

【QPS計算PV和機器的方式】

QPS統計方式 [一般使用 http_load 進行統計]
QPS = 總請求數 / ( 程序總數 * 請求時間 )
QPS: 單個程序每秒請求伺服器的成功次數

單臺伺服器每天PV計算
公式1:每天總PV = QPS * 3600 * 6
公式2:每天總PV = QPS * 3600 * 8

伺服器計算
伺服器數量 = ceil( 每天總PV / 單臺伺服器每天總PV )

【峰值QPS和機器計算公式】

原理:每天80%的訪問集中在20%的時間裡,這20%時間叫做峰值時間
公式:( 總PV數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(QPS)
機器:峰值時間每秒QPS / 單臺機器的QPS = 需要的機器

問:每天300w PV 的在單臺機器上,這臺機器需要多少QPS?
答:( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)

問:如果一臺機器的QPS是58,需要幾臺機器來支援?
答:139 / 58 = 3

TPS:每秒鐘處理完的事務次數,一般TPS是對整個系統來講的。一個應用系統1s能完成多少事務處理,一個事務在分散式處理中,可能會對應多個請求,對於衡量單個介面服務的處理能力,用QPS比較多。

併發量級說明:
評價一個網站的“大小”,處於視角的不同,有很多種衡量的方法,類似文章數,頁面數之類的資料非常明顯,也沒有什麼可以爭議的。但對於併發來說,爭議非常之多,這裡就從一個技術的角度開始,談談幾個Web網站的數量級。

相信很多人談論一個網站的熱度,總免不了會詢問日均PV,同時線上人數、註冊使用者數等運營資料,說實話從技術角度來說,這幾個數值沒有一個可以放在一起比較的——一個靜態網站的PV跟一個SNS類/Web Game網站的PV根本就不是一回事。由於網際網路有一個傳說中的“3秒定律”,可能當下更多的網站技術指標要求1.5秒以內載入整頁,或者至少可以達到閱讀的標準。如果要較真什麼“同時線上”,毫不客氣的說,對於HTTP這類短連結的網路協議來說,在WebSocket還不普及的時代,能統計線上純屬扯淡,唯一能做的只是取個時間段,計算下訪問使用者而已。這些依然可以換算成QPS(Quest Per Second每秒請求數)。就併發而言,我唯一推崇的只有理論最大QPS和悲觀QPS。

這裡就大致根據理論最大QPS,給網站做幾個分類

50QPS以下——小網站

沒什麼好說的,簡單的小網站而已,你可以用最簡單的方法快速搭建,短期沒有太多的技術瓶頸,只要伺服器不要太爛就好。

50~100QPS——DB極限型

大部分的關係型資料庫的每次請求大多都能控制在0.01秒左右,即便你的網站每頁面只有一次DB請求,那麼頁面請求無法保證在1秒鐘內完成100個請求,這個階段要考慮做Cache或者多DB負載。無論那種方案,網站重構是不可避免的。

300~800QPS——頻寬極限型

目前伺服器大多用了IDC提供的“百兆頻寬”,這意味著網站出口的實際頻寬是8M Byte左右。假定每個頁面只有10K Byte,在這個併發條件下,百兆頻寬已經吃完。首要考慮是CDN加速/異地快取,多機負載等技術。

500~1000QPS——內網頻寬極限+Memcache極限型

由於Key/value的特性,每個頁面對memcache的請求遠大於直接對DB的請求,Memcache的悲觀併發數在2w左右,看似很高,但事實上大多數情況下,首先是有可能在次之前內網的頻寬就已經吃光,接著是在8K QPS左右的情況下,Memcache已經表現出了不穩定,如果程式碼上沒有足夠的優化,可能直接將壓力轉嫁到了DB層上,這就最終導致整個系統在達到某個閥值之上,效能迅速下滑。

1000~2000QPS——FORK/SELECT,鎖模式極限型

好吧,一句話:執行緒模型決定吞吐量。不管你係統中最常見的鎖是什麼鎖,這個級別下,檔案系統訪問鎖都成為了災難。這就要求系統中不能存在中央節點,所有的資料都必須分佈儲存,資料需要分佈處理。總之,關鍵詞:分佈

2000QPS以上——C10K極限

儘管現在很多應用已經實現了C25K,但短板理論告訴我們,決定網站整體併發的永遠是最低效的那個環節。我承認我生涯中從未遇到過2000QPS以上,甚至1.5K以上的網站,希望有此經驗的哥們可以一起交流下

作者:昌昌93
來源:CSDN
原文:https://blog.csdn.net/u014044812/article/details/79403301
版權宣告:本文為博主原創文章,轉載請附上博文連結!