每個(gè)公司都有自己的基因。做產(chǎn)品起家的，和網(wǎng)絡(luò)公司不同。對(duì)于性能測(cè)試，很多的思維還停留在單機(jī)時(shí)代。于是很多QA就認(rèn)為，無非就是測(cè)試CPU，memory，disk等參數(shù)而已。
但是隨著后臺(tái)的service程序逐漸增多，service的性能測(cè)試，和之前測(cè)試一個(gè)產(chǎn)品，已經(jīng)有了很多的不同。這里，就談?wù)勥@次性能測(cè)試的一些經(jīng)驗(yàn)。
其實(shí)之前QA已經(jīng)做過了一些性能測(cè)試。但是有一天我們計(jì)劃購(gòu)入機(jī)器為產(chǎn)品上線做準(zhǔn)備，manager問我如何購(gòu)買機(jī)器。我一看module不少，首先就考慮如何分配這些moudule在不同的機(jī)器上，以獲得最好的性能。于是我要搞清楚每個(gè)module的性能瓶頸，到底是cpu bound，還是IO bound，還是memory bound。
我就建議QA做了這樣的測(cè)試。測(cè)試結(jié)果出來了。從結(jié)果看來，掃描病毒的模塊CPU還是一個(gè)瓶頸，畢竟，掃描病毒是一個(gè)很耗時(shí)的操作。而web service則需要較多的memory。
我后面關(guān)心的就是那么多模塊協(xié)同工作，誰是最慢的環(huán)節(jié)。因?yàn)槲覀冎暗脑O(shè)計(jì)還是考慮的拓展性，所以，對(duì)于最慢的環(huán)節(jié)，通過增加進(jìn)程數(shù)目和增加機(jī)器可以改善。
結(jié)果出來了，QA很快就根據(jù)他們的性能，給出了一組最小的機(jī)器配置列表。哪些module可以放在一起，每個(gè)module至少要起幾個(gè)進(jìn)程才不至于出現(xiàn)特別慢的module block整個(gè)service的效率。這下就簡(jiǎn)單了。我們可以把它作為一個(gè)service組，以后增加機(jī)器，就按照這樣的配置成倍的增加。
其實(shí)這樣的思路，就是現(xiàn)在所謂的SOA運(yùn)維。別人問你需要多少機(jī)器，如何擴(kuò)容，你給出的不是幾臺(tái)機(jī)器，而是以一個(gè)最小的service集群組為單位的系統(tǒng)配置。比如說你的service有3個(gè)模塊，他們的配置可能是
模塊 數(shù)目 特征
A 1 CPU bound
B 2 IO bound
C 1 memory bound
意味這增加一個(gè)A和C，需要兩個(gè)B配合。
這樣，最小的配置就是 1 cpu，2 disk，1 memory，有可能對(duì)于到服務(wù)器上面，就是
8core cpu
15000 PRM SAS disk *2
32G memory
有了這樣的最小單位，下面才是真正的性能測(cè)試環(huán)節(jié)，我們要知道，這個(gè)最小的service單位，能夠有多大的吞吐量。
于是，盡可以多地喂數(shù)據(jù)，看看輸出的效率。這時(shí)，我們關(guān)心的已經(jīng)不是cpu、memory、io這些參數(shù)了，因?yàn)槟愕淖钚∨渲帽仨毷沁@樣的。你可能會(huì)浪費(fèi)CPU，浪費(fèi)內(nèi)存，但是沒有辦法，因?yàn)槠款i在那里，要增加機(jī)器提高整體吞吐量，IO是瓶頸。 我們關(guān)心的是，整個(gè)最小的service集合到底能有多大的吞吐量。如果我要更大的吞吐量，需要多少個(gè)這樣的service單位。
這樣的性能測(cè)試結(jié)果，對(duì)產(chǎn)品，對(duì)運(yùn)維才是真正有意義的。這就是從整體的角度去考慮一個(gè)service產(chǎn)品。而這也為RD后期的開發(fā)起了指導(dǎo)意義，哪個(gè)模塊是重頭戲，對(duì)整體而言起決定意義。需要重點(diǎn)調(diào)優(yōu)，哪個(gè)模塊雖然效率很低，但是調(diào)優(yōu)的優(yōu)先級(jí)可以放低。因?yàn)樗皇顷P(guān)鍵。
這里的關(guān)鍵，就在于強(qiáng)調(diào)整體測(cè)試。而且這個(gè)整體是建立在之前模塊測(cè)試后的模塊配比的基礎(chǔ)上的。強(qiáng)調(diào)最小service集合的測(cè)試。