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