Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you what are the parameters of Dubbo concurrent tuning. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

Consumer side tuning:

1. Connections

This parameter can be configured when the service provider publishes the service, or when the consumer refers to the service, but this value only takes effect on the consumer side, so it is generally not recommended to configure the service provider. If configured, please consider. Whether on the consumer side or the service provider side, if the connections parameter is configured for a service and the parameter is greater than 1, it will cause the consumer side to initialize a private socketclient for the service when creating a remote socketclient for the service (if it is the dubbo protocol). Therefore, it is generally not recommended to adjust this value.

Server optimization adjustment:

Compared with the remaining consumer side, the server-side tuning parameters are relatively more, but the configuration also needs to be careful.

1. Executes

This parameter can be accurate to the method level, that is, you can specify that it is the value of the parameter that invokes a method on the remote interface. Exactly how to configure it can be seen in the official documentation. Here, it just describes the actual meaning of this parameter and should pay attention to it when using it.

To talk about this parameter, you need to introduce ExecuteLimitFilter, who is the user of this parameter. When you see Filter, you should understand it, that is, add business logic before and after each method request. The code inside is posted below:

@ Activate (group = Constants.PROVIDER, value = Constants.EXECUTES_KEY)

Public class ExecuteLimitFilter implements Filter {

Public Result invoke (Invoker invoker, Invocation invocation) throws RpcException {

URL url = invoker.getUrl ()

String methodName = invocation.getMethodName ()

Int max = url.getMethodParameter (methodName, Constants.EXECUTES_KEY, 0)

If (max > 0) {

RpcStatus count = RpcStatus.getStatus (url, invocation.getMethodName ())

If (count.getActive () > = max) {

Throw new RpcException ("Failed to invoke method" + invocation.getMethodName () + "in provider" + url + ", cause: The service using threads greater than limited.")

}

}

Long begin = System.currentTimeMillis ()

Boolean isException = false

RpcStatus.beginCount (url, methodName)

Try {

Result result = invoker.invoke (invocation)

Return result

} catch (Throwable t) {

IsException = true

If (t instanceof RuntimeException) {

Throw (RuntimeException) t

}

Else {

Throw new RpcException ("unexpected exception when ExecuteLimitFilter", t)

}

}

Finally {

RpcStatus.endCount (url, methodName, System.currentTimeMillis ()-begin, isException)

}

}

}

The above code mainly looks at two places, line 7 and line 10, respectively, line 7 is to get the value of the configured executes, which is of type int, describing the number, and then line 10 is to get the current state of the current request method, in which there is an active attribute (this attribute is of type AtomacInteger, and you should understand why this type is used), indicating the number of threads in the execution state of the current request method. If this value is greater than or equal to the configured value, then the consumer will receive an exception of RPC and cause the call to the service to fail, which is the final effect of this parameter.

II. Actives

This parameter is basically the same as excetes, but it is a little different. Before you say this is different, take a look at another Filter. You should know what it does by looking at the name-- ActiveLimitFilter, and the code is also posted below:

@ Activate (group = Constants.CONSUMER, value = Constants.ACTIVES_KEY)

Public class ActiveLimitFilter implements Filter {

Public Result invoke (Invoker invoker, Invocation invocation) throws RpcException {

URL url = invoker.getUrl ()

String methodName = invocation.getMethodName ()

Int max = invoker.getUrl () .getMethodParameter (methodName, Constants.ACTIVES_KEY, 0)

RpcStatus count = RpcStatus.getStatus (invoker.getUrl (), invocation.getMethodName ())

If (max > 0) {

Long timeout = invoker.getUrl () .getMethodParameter (invocation.getMethodName (), Constants.TIMEOUT_KEY, 0)

Long start = System.currentTimeMillis ()

Long remain = timeout

Int active = count.getActive ()

If (active > = max) {

Synchronized (count) {

While ((active = count.getActive ()) > = max) {

Try {

Count.wait (remain)

} catch (InterruptedException e) {

}

Long elapsed = System.currentTimeMillis ()-start

Remain = timeout-elapsed

If (remain 0) {

Synchronized (count) {

Count.notify ()

}

}

}

}

}

The above code is roughly the same as executes, except that there is an extra wait time. When the current thread executing the method exceeds the maximum limit, you can wait for a timeout time. If the time has elapsed or exceeded the maximum limit, an exception is thrown. This is a little softer than Yu executes. That's the difference!

III. Accepts

Take a look at the meaning of this parameter before looking at the code, which tells the service provider how many consumers can receive to connect to the service provider. The next step is the code, and this parameter is represented in the class AbstractServer. The code is as follows:

To talk about this parameter, you need to introduce ExecuteLimitFilter, who is the user of this parameter. When you see Filter, you should understand it, that is, add business logic before and after each method request. The code inside is posted below:

@ Override

Public void connected (Channel ch) throws RemotingException {

Collection channels = getChannels ()

If (accepts > 0 & & channels.size () > accepts) {

Logger.error ("Close channel" + ch +, cause: The server "+ ch.getLocalAddress () +" connections greater than max config "+ accepts)

Ch.close ()

Return

}

Super.connected (ch)

}

This method is triggered when each consumer creates a socket connection to the service provider. You can clearly see that if the number of consumers connecting the current server exceeds the configured value, the request for the current consumer connection will be closed. This is only a limit on the number of socket connections, not the configuration of the calling thread like the above two parameters.

The above parameters suggest that the server-side configuration takes effect on the server side and the consumer-side configuration takes effect on the consumer side, otherwise it will lead to some uncontrollable phenomena. This is also called that the things should be where they are changed, and should not be misplaced.

These are the parameters of the Dubbo concurrent tuning shared by the editor. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.