今天開始對之前所能夠想到的一些問題進行一些理論解決方案的研究。
首先，1000萬的用戶可以造成多么大的並發數量，應該是可以被計算出來的。我通過百度進行了一些搜索，關於用戶數量與並發數的關系。
得到了一些資料，主要參考了一篇名為《並發用戶數、吞吐量、思考時間的計算公式》的文檔。
其中提到了關於性能需要考慮的幾個方面，這些內容稍后再討論。主要先說說幾個公式
1.平均並發用戶數的計算公式
C=nL / T
其中C是平均的並發用戶數，n是平均每天訪問用戶數，L是一天內用戶從登錄到退出的平均時間（操作平均時間），T是考察時間長度（一天內多長時間有用戶使用系統）
2.並發用戶數峰值計算公式
C’ ≈ C+3根號C
其中，C’指並發用戶數的峰值，C即是平均並發用戶數。該公式的得出是假設用戶的login session產生符合泊松分布而估算得到的
至於為什么會是這樣一個公式來計算，我並未深究，也不知道其原因，目前看來，我也還不明白泊松分布是什么，用戶session為什么會產生泊松分布。我也不知道。我所能了解到的就是這些計算方式一定各種前輩總結出的。先拿來得出結論，后續再去剖析這些原由吧。在此我們暫且保留這些問題，日后分解。
既然這2個公式我們來假設一下1000萬用戶可能會產生的並發情況
1.n每天訪問用戶數量=1000萬
2.假設這個服務是用作網上銀行的操作，L=一天內用戶從登陸到退出的平均時間設為（5分鍾），T假設每天早晨8點-12點，均有用戶訪問。時長16小時即960分鍾。
（這個用戶數量，我們就假定為平均每天訪問系統的用戶數，如果是總用戶數量，那么則需要先算出1000萬用戶，每天平均有多少用戶訪問。）
C=10000000*5/960=52083.33/m （即52083.33每分鍾）
3.並發用戶峰值為
C' ≈ 52083.33+3*根號52083.33=52083.33+3*228.22=52767
感覺有點奇怪的樣子,也許是我的一些參數設定不合理吧,或許這些並發數量的計算不應以天為單位,而應以忙時,閑時來划分,也許更為精確.無論如何,先根據這個想法進行探索假設吧.
但是需要強調的是,我在網上找到的資料中,有些計算是以小時得出的結果,有些是以分鍾得出的結果.我這里使用的是分鍾計算.所以我認為,平均並發用戶數應該是有一個時間作為其單位的.
回到文章開頭的話題,在搜索關於用戶數量與並發數量的關系時還發現了幾個專業的名詞.會對性能產生影響.
1.響應時間:顧名思義了,對用戶請求作出響應所需要的時間
2.吞吐量:指單位時間內系統處理用戶的請求數
從業務角度看，吞吐量可以用：請求數/秒、頁面數/秒、人數/天或處理業務數/小時等單位來衡量
從網絡角度看，吞吐量可以用：字節/秒 來衡量
對於交互式應用來說，吞吐量指標反映的是服務器承受的壓力，他能夠說明系統的負載能力.
這里引用的都是查找來的文字,那么看起來說明的問題,但是給人感覺還是一知半解.希望可以在以后找到更多關於吞吐量的負載實例來說明吞吐量這個概念,把這些專業的名詞屌絲化.
3.資源利用率
指系統各種資源的使用情況，如cpu占用率為68%，內存占用率為55%，一般使用“資源實際使用/總的資源可用量”形成資源利用率。
對於資源利用率如果讓我用自己的理解來表述的話,應該是服務器相關的各種硬件軟件的使用度,這個比例的高低會有什么樣的后果,我還沒有深思.也還沒來得及去來查閱關於資源使用以及平衡的一些知識.這里再給自己留下一個問題吧.
4.思考時間
從業務角度來看，這個時間指用戶進行操作時每個請求之間的時間間隔，而在做性能測試時，為了模擬這樣的時間間隔，引入了思考時間這個概念，來更加真實的模擬用戶的操作。這個解釋,作為一個大白話王子,我覺得我這句話算是比較白了,不需要再進行翻譯.目的可能就是為了提高性能測試的仿真度吧.
下面給出一個計算思考時間的一般步驟：
A、 首先計算出系統的並發用戶數
C=nL / T F=R×C
B、 統計出系統平均的吞吐量
F=VU * R / T R×C = VU * R / T
C、 統計出平均每個用戶發出的請求數量
R=u*C*T/VU
D、根據公式計算出思考時間
TS=T/R
本次關於用戶數量以及並發數量的解決方案研究,我們計算出了1000萬用戶數量,每分鍾的平均並發數量,以及峰值數量.
同時也注意到了,其他4會對性能產生影響的概念.
又再次引發了2個問題,
8.關於吞吐量的與服務器性能的關系.
9.資源利用率與性能的關系.
希望可以在后續的學習中,對這些知識進行白話式的解決方案研究.