Dubbo調優經歷

原型階段，主要影響如下：

服務的日誌I/O 會影響效能。

資料庫的I/O 會嚴重影響效能。

服務的部署情況 會影響效能。

原型優化：

1.優化資料庫，嘗試使用記憶體，增大記憶體buff。

2.調整服務部署，服務間呼叫，由於該宿主機器的cpu佔用率不同和磁碟I/O網路等不同，需要不斷的嘗試服務部署機器之間的分配，要將需求資源大的服務部署在較好的環境，並且競爭較少的情況可以提升tps。

3. 服務本身耗時極低，幾乎忽略。

4.將呼叫者和被呼叫者儘量部署在同一宿主機，可以降低一部分耗時。

5.將所有服務部署在一臺非常好的機器 32U 128G機器上，CPU /記憶體皆沒達到瓶頸，將資料庫部署在另外一臺這樣的PC物理機上，延遲會大大降低，但是依然存在RPC呼叫在400併發下8-10秒的耗時。（後續可以優化這個RPC耗時） 

過程：

使用工具:

Linux 常用工具包

Jemeter http post請求

涉及中介軟體:

Zookeeper

Redis

原型階段：

共涉及服務10個，涉及資料庫5個。內部協議 dubbo 對外協議:rest

部署大致如下:

3臺pc機，3臺宿主機，超分，每個虛機上部署一個服務。大致是宿主機4顆8核2GHz *2、4顆6核心1.87GHx  *1、4C8G PC機8臺。

部署完後直接使用jemeter跑出結果 1700TPS。

現象：各服務和資料庫的cpu都不高，三臺資料庫io很高，相關應用服務出現網路阻塞等待。

分析結果：三臺資料庫插入操作多，資料庫伺服器的磁碟io達到瓶頸

改動1:因為資源有限，無法顧及I/O問題，顧臨時修改資料庫為記憶體寫，不落盤。TPS提升

但是檢視到redis記憶體消耗不足,redis伺服器記憶體達到瓶頸

此時tps:2400

改動2: 將Redis移至主頻和記憶體高的pc機，資源有限，將原本pc機上的服務移至虛機。

Tps提示至2800

資源有限，沒有進一步測試。

後將服務的分佈調整更合理之後，並將資料庫部署在本地PC機上，磁碟IO 單執行緒10M/s的情況下，併發數400達到TPS 3800.

Duboo單服務呼叫，使用rest介面，TPS 1W9（關掉日誌等IO影響）（開啟日誌1W3 達到寫日誌磁碟I/O瓶頸 寫等待出現佇列 utils 90%）