As a service governance framework, dubbo has relatively complete functions and good performance. However, when many friends use dubbo, they simply refer to the official instructions for construction, and do not think too much about the meaning of some key parameters (it may also be that there are too many tasks and there is no time for research), and the final effect is achieved. There are certain discounts. Here I list several performance tuning parameters and their meanings based on the current usage of our project for your reference.
Before introducing the parameters, let's first understand the priority of the configuration in dubbo, so as to avoid the problem of setting the tuning parameters but not finding the effect is actually caused by the configuration being overwritten. Dubbo is divided into consumer and provider. When configuring each parameter, its priority is as follows:
1. The method configuration of the consumer
2. The method configuration of the provider
3. The reference configuration of the consumer
4. The service configuration of the provider
5. The consumer node configuration of the consumer
6. Provider node configuration of provider
It can be seen that the configuration priority of method level is higher than that of interface level, and the priority of consumer is higher than that of provider. At the same time, there is also a layer of priority in the local parameter configuration:
1. System parameters (-D), such as -Ddubbo.protocol.port=20881
2. XML configuration
3. The property file
understands these two priorities and tunes them It will be clearer, saving some troubles such as configuration settings not taking effect. Note that in fact, dubbo can also overwrite the user configuration by writing the configuration to the registration center (the priority is higher than the system parameter). It is not expanded here. Interested students can go to the official document. Next, let's take a look at some of the more important tuning parameters of dubbo, and how they affect them and their approximate implementation.
Parameter name Scope Default value Description Remarks
actives consumer 0 Maximum number of concurrent calls per service consumer per service per method 0 means unlimited
connections consumer maximum number of connections to each provider, short connection protocols such as rmi, http, hessian indicate restrictions The number of connections, dubbo and other long-term connection associations indicate that the number of long-term connections established is 1 when dubbo, and multiplexing a single link
accepts provider 0 The maximum number of connections the service provider can accept 0 means
unlimited iothreads provider cpu number + 1 io thread pool Size (fixed size)
threads provider 200 Business thread pool size (fixed size)
executes provider 0 Service provider The maximum number of parallel execution requests per service per method 0 means
unlimited tps provider Maximum execution times within the specified time (default 60s) , note that the difference from executes is not enabled by default
Pay attention to the corresponding relationship between the parameters in the table and the figure:
1. When the consumer initiates a request, it first restricts the method level through the active limit (parameter actives), which is implemented by storing the counter (AtomicInteger) in the CHM and adding 1 to the request. , the request is completed (including exceptions) minus 1, if it exceeds actives, wait for other requests to complete and retry or fail after timeout;
2. Select a connection from multiple connections to send data, for the default netty implementation , since connections can be reused, one connection is sufficient by default. However, if you are stress testing, and there is only one consumer and one provider, then appropriately increasing the connections can indeed enhance the network transmission capacity. However, since there are multiple consumers and multiple providers in the online business, it is not recommended to increase the connections parameter;
3. When the connection reaches the provider (such as the initial connection of dubbo), it will first determine whether the total number of connections exceeds the limit (accepts), and the connection exceeds the limit. will be rejected;
4. After the connection is successful, the specific request will be handed over to the io thread for processing. Although io threads process data reading and writing, the io part is asynchronous and consumes more CPU. Therefore, the default number of CPUs + 1 for iothreads is a reasonable setting. It is not recommended to adjust this parameter;
5. Data read and After deserialization, it is handed over to the business thread pool for processing. By default, the thread pool is fixed and the queue is 0 (queues). In this case, the maximum concurrency is equal to the business thread pool size (threads). Stacking ability, you can adjust the queues parameter. If you want fast failure to be handled by other nodes (the official recommended way), do not modify queues, only adjust threads;
6. execute limit (parameter executes) is a method-level concurrency limit. The principle is similar to that of actives, except that the waiting process is less, that is, it fails immediately after being limited;
7. tps, which controls the number of requests within a specified time (default 60s). Note that currently dubbo does not support this parameter by default, you need to add a META-INF/dubbo/com.alibaba.dubbo.rpc.Filter file, the content of the file is:
tps=com.alibaba.dubbo.rpc.filter.TpsLimitFilter
From the above analysis, it can be seen that if the number of consumers*actives>the number of providers*threads and queues=0, there will be some requests that cannot apply for resources, and there is a high probability of failure in retrying. Use executes when you need different concurrency control for different methods of an interface, otherwise you can adjust threads.