來自於：https://blog.csdn.net/youaremoon/article/details/51884644
感謝博主，收藏一下
dubbo作為一個服務治理框架，功能相對比較完善，性能也挺不錯。但很多朋友在使用dubbo的時候，只是簡單的參考官方說明進行搭建，並沒有過多的去思考一些關鍵參數的意義（也可能是時間緊任務多，沒空出來研究），最終做出來的效果有一定的打折。 這里我根據目前我們項目的使用情況列出幾個性能調優的參數及其意義，供大家參考。
在介紹參數之前，我們先了解下dubbo中配置的優先級，以免出現調優參數設置了卻沒發現效果實際是配置被覆蓋導致這樣的問題。dubbo分為consumer和provider端，在配置各個參數時，其優先級如下：
1、consumer的method配置
2、provider的method配置
3、consumer的reference配置
4、provider的service配置
5、consumer的consumer節點配置
6、provider的provider節點配置
可以看到，方法級的配置優先級高於接口級，consumer的優先級高於provider。同時，在本地參數配置還存在一層優先級：
1、系統參數(-D)，如-Ddubbo.protocol.port=20881
2、xml配置
3、property文件
了解了這兩個優先級，調優起來才會更加清晰，省去了一些諸如配置設置了不生效這樣的麻煩。注意，其實dubbo中還可以通過將配置寫入注冊中心的方式覆蓋用戶配置（優先級高於系統參數），這里不展開，有興趣的同學可以去看官方文檔。接下來我們看看dubbo的幾個比較重要的調優參數，及其影響的方式和大概實現。
| 參數名 | 作用范圍 | 默認值 | 說明 | 備注 |
|---|---|---|---|---|
| actives | consumer | 0 | 每服務消費者每服務每方法最大並發調用數 | 0表示不限制 |
| connections | consumer | 對每個提供者的最大連接數，rmi、http、hessian等短連接協議表示限制連接數，dubbo等長連接協表示建立的長連接個數 | dubbo時為1，及復用單鏈接 | |
| accepts | provider | 0 | 服務提供方最大可接受連接數 | 0表示不限制 |
| iothreads | provider | cpu個數+1 | io線程池大小(固定大小) | |
| threads | provider | 200 | 業務線程池大小(固定大小) | |
| executes | provider | 0 | 服務提供者每服務每方法最大可並行執行請求數 | 0表示不限制 |
| tps | provider | 指定時間內（默認60s）最大的可執行次數，注意與executes的區別 | 默認不開啟 |
注意表中參數與圖中的對應關系：
1、當consumer發起一個請求時，首先經過active limit(參數actives）進行方法級別的限制，其實現方式為CHM中存放計數器(AtomicInteger)，請求時加1，請求完成（包括異常）減1,如果超過actives則等待有其他請求完成后重試或者超時后失敗；
2、從多個連接(connections）中選擇一個連接發送數據，對於默認的netty實現來說，由於可以復用連接，默認一個連接就可以。不過如果你在壓測，且只有一個consumer,一個provider，此時適當的加大connections確實能夠增強網絡傳輸能力。但線上業務由於有多個consumer多個provider，因此不建議增加connections參數；
3、連接到達provider時（如dubbo的初次連接），首先會判斷總連接數是否超限（acceps），超過限制連接將被拒絕；
4、連接成功后，具體的請求交給io thread處理。io threads雖然是處理數據的讀寫，但io部分為異步，更多的消耗的是cpu，因此iothreads默認cpu個數+1是比較合理的設置，不建議調整此參數;
5、數據讀取並反序列化以后，交給業務線程池處理，默認情況下線程池為fixed，且排隊隊列為0(queues)，這種情況下，最大並發等於業務線程池大小(threads)，如果希望有請求的堆積能力，可以調整queues參數。如果希望快速失敗由其他節點處理（官方推薦方式），則不修改queues，只調整threads;
6、execute limit（參數executes）是方法級別的並發限制，原理與actives類似，只是少了等待的過程，即受限后立即失敗；
7、tps，控制指定時間內（默認60s）的請求數。注意目前dubbo默認沒有支持該參數，需要加一個META-INF/dubbo/com.alibaba.dubbo.rpc.Filter文件，文件內容為：
tps=com.alibaba.dubbo.rpc.filter.TpsLimitFilter
從上面的分析，可以看出如果consumer數*actives>provider數*threads且queues=0，則會存在部分請求無法申請到資源，重試也有很大幾率失敗。 當需要對一個接口的不同方法進行不同的並發控制時使用executes，否則調整threads就可以。