Dubbo 併發調優的幾個引數

消費端調優：

一、connections

這個引數可以在服務提供端發布服務的時候配置，也可以在消費端引用服務的時候配置，但是這個值是只對消費端生效的，所以一般是服務提供端不建議配置，如果配置，請斟酌一下，詳情請檢視《對connections引數的設定》。不管是在消費端或者服務提供端，如果對某個服務配置了connections引數，並且該引數大於1，那麼就會導致消費端在建立該服務的遠端socketclient的時候（如果是dubbo協議的話）將會給該服務初始化乙個私有的socketclient。所以一般不建議對這個值進行調整。

服務端優化調整：

相對餘消費端，服務端調優的引數相對多一些，但是配置的時候也需要謹慎。

一、executes

這個引數是可以精確到方法級別的引數，就是可以指定呼叫遠端介面某個方法的是該引數的值。具體是怎麼配置的可以到官方文件裡面去看看那，這裡只是描述這個引數實際意義以及使用的時候應該注意點。

要說這個引數，就要所介紹

executelimitfilter，

@activate(group = constants.provider, value = constants.executes_key)
public class executelimitfilter implements filter 
}long begin = system.currenttimemillis();
boolean i***ception = false;
rpcstatus.begincount(url, methodname);
try  catch (throwable t) 
else 
}finally 
}}

上面這段**主要是看兩個地方，分別是第7行和第10行，第7行是獲取配置的executes的值，是乙個int型別的，描述數量，然後第10行是獲取當前請求方法當前的狀態，裡面既有乙個active屬性(該屬性是atomacinteger型別的，大家應該懂了為什麼用這個型別)，表示當前請求的方法處於執行狀態的執行緒數量，如果這個值大於或者等於配置的值那麼直接丟擲異常，那麼消費端就會收到乙個rpc的異常導致呼叫服務失敗，這是這個引數最終導致的效果。

二、actives

這個引數基本上和excetes一樣，但是有一點不同，在說這不同之前，還是看看另乙個filter,看名字你們應該就知道它是做什麼的了——

activelimitfilter，下面同樣貼出**：

@activate(group = constants.consumer, value = constants.actives_key)
public class activelimitfilter implements filter  catch (interruptedexception e) 
long elapsed = system.currenttimemillis() - start;
remain = timeout - elapsed;
if (remain <= 0) }}
}}
try  catch (runtimeexception t) 
} finally }}
}}

上面**大致上和executes一樣，唯一不同的就是多了乙個等待時間，當當前執行該方法的執行緒超出了最大限制，那麼可以等待乙個timeout時間，如果時間過了還是超出了最大限制，那麼就丟擲異常。這個相對餘executes來說溫柔那麼點。這就是那點不同！

三、accepts

在看**之前先看看這個引數的意思，這個引數是告知服務提供端能接收多少個消費端連線該服務提供方。下面接著上**，這個引數的體現是在類abstractserver中。**如下：

@override
public void connected(channel ch) throws remotingexception 
super.connected(ch);
}

這個方法是每個消費端向服務提供端建立乙個socket連線的時候都會觸發，上面可以清晰看到如果連線當前服務端的消費端數量超出了配置的值，那麼將會關閉當前消費端連線的請求。這個只是對socket連線的數量限制，而不是像上面兩個引數對呼叫執行緒的配置。

以上歸納出的幾個引數建議服務端生效的在服務端配置，消費端生效的在消費端配置，不然會導致一些不可控的現象出現。這也叫改**的東西就應該在**，而不能亂放。

Dubbo 併發調優的幾個引數

Dubbo 併發調優的幾個引數

Dubbo常用調優引數

Hadoop調優的幾個引數

Dubbo 併發調優的幾個引數

Dubbo 併發調優的幾個引數

Dubbo常用調優引數

Hadoop調優的幾個引數

相關推薦