點擊上方“藍色字體”，選擇“設為星標”

做積極的人，而不是積極廢人！

作者 |?nxlhero

來源 |?https://blog.51cto.com/nxlhero/2515849

文章內容結構

第一部分介紹生產(chǎn)上出現(xiàn)Dubbo服務擁堵的情況，以及Dubbo官方對于單個長連接的使用建議。

第二部分介紹Dubbo在特定配置下的通信過程，輔以代碼。

第三部分介紹整個調用過程中與性能相關的一些參數(shù)。

第四部分通過調整連接數(shù)和TCP緩沖區(qū)觀察Dubbo的性能。

一、背景

生產(chǎn)擁堵回顧

近期在一次生產(chǎn)發(fā)布過程中，因為突發(fā)的流量，出現(xiàn)了擁堵。系統(tǒng)的部署圖如下，客戶端通過Http協(xié)議訪問到Dubbo的消費者，消費者通過Dubbo協(xié)議訪問服務提供者。這是單個機房，8個消費者3個提供者，共兩個機房對外服務。

在發(fā)布的過程中，摘掉一個機房，讓另一個機房對外服務，然后摘掉的機房發(fā)布新版本，然后再互換，最終兩個機房都以新版本對外服務。問題就出現(xiàn)單機房對外服務的時候，這時候單機房還是老版本應用。以前不知道晚上會有一個高峰，結果當晚的高峰和早上的高峰差不多了，單機房扛不住這么大的流量，出現(xiàn)了擁堵。這些流量的特點是并發(fā)比較高，個別交易返回報文較大，因為是一個產(chǎn)品列表頁，點擊后會發(fā)送多個交易到后臺。

在問題發(fā)生時，因為不清楚狀態(tài)，先切到另外一個機房，結果也擁堵了，最后整體回退，折騰了一段時間沒有問題了。當時有一些現(xiàn)象：

(1)提供者的CPU內存等都不高，第一個機房的最高CPU 66%(8核虛擬機)，第二個機房的最高CPU 40%(16核虛擬機)。消費者的最高CPU只有30%多(兩個消費者結點位于同一臺虛擬機上)

(2)在擁堵的時候，服務提供者的Dubbo業(yè)務線程池(下面會詳細介紹這個線程池)并沒滿，最多到了300，最大值是500。但是把這個機房摘下后，也就是沒有外部的流量了，線程池反而滿了，而且好幾分鐘才把堆積的請求處理完。

(3)通過監(jiān)控工具統(tǒng)計的每秒進入Dubbo業(yè)務線程池的請求數(shù)，在擁堵時，時而是0，時而特別大，在日間正常的時候，這個值不存在為0的時候。

事故原因猜測

當時其他指標沒有檢測到異常，也沒有打Dump，我們通過分析這些現(xiàn)象以及我們的Dubbo配置，猜測是在網(wǎng)絡上發(fā)生了擁堵，而影響擁堵的關鍵參數(shù)就是Dubbo協(xié)議的連接數(shù)，我們默認使用了單個連接，但是消費者數(shù)量較少，沒能充分把網(wǎng)絡資源利用起來。

關注公眾號：后端面試那些事兒，每天學一點，一起進大廠！

默認的情況下，每個Dubbo消費者與Dubbo提供者建立一個長連接，Dubbo官方對此的建議是：

Dubbo 缺省協(xié)議采用單一長連接和 NIO 異步通訊，適合于小數(shù)據(jù)量大并發(fā)的服務調用，以及服務消費者機器數(shù)遠大于服務提供者機器數(shù)的情況。

反之，Dubbo 缺省協(xié)議不適合傳送大數(shù)據(jù)量的服務，比如傳文件，傳視頻等，除非請求量很低。

(http://dubbo.apache.org/zh-cn/docs/user/references/protocol/dubbo.html)

以下也是Dubbo官方提供的一些常見問題回答：

為什么要消費者比提供者個數(shù)多?

因 dubbo 協(xié)議采用單一長連接，假設網(wǎng)絡為千兆網(wǎng)卡，根據(jù)測試經(jīng)驗數(shù)據(jù)每條連接最多只能壓滿 7MByte(不同的環(huán)境可能不一樣，供參考)，理論上 1 個服務提供者需要 20 個服務消費者才能壓滿網(wǎng)卡。

為什么不能傳大包?

因 dubbo 協(xié)議采用單一長連接，如果每次請求的數(shù)據(jù)包大小為 500KByte，假設網(wǎng)絡為千兆網(wǎng)卡，每條連接最大 7MByte(不同的環(huán)境可能不一樣，供參考)，單個服務提供者的 TPS(每秒處理事務數(shù))最大為：128MByte / 500KByte = 262。單個消費者調用單個服務提供者的 TPS(每秒處理事務數(shù))最大為：7MByte / 500KByte = 14。如果能接受，可以考慮使用，否則網(wǎng)絡將成為瓶頸。

為什么采用異步單一長連接?

因為服務的現(xiàn)狀大都是服務提供者少，通常只有幾臺機器，而服務的消費者多，可能整個網(wǎng)站都在訪問該服務，比如 Morgan 的提供者只有 6 臺提供者，卻有上百臺消費者，每天有 1.5 億次調用，如果采用常規(guī)的 hessian 服務，服務提供者很容易就被壓跨，通過單一連接，保證單一消費者不會壓死提供者，長連接，減少連接握手驗證等，并使用異步 IO，復用線程池，防止 C10K 問題。

因為我們的消費者數(shù)量和提供者數(shù)量都不多，所以很可能是連接數(shù)不夠，導致網(wǎng)絡傳輸出現(xiàn)了瓶頸。以下我們通過詳細分析Dubbo協(xié)議和一些實驗來驗證我們的猜測。

二、Dubbo通信流程詳解

我們用的Dubbo版本比較老，是2.5.x的，它使用的netty版本是3.2.5，最新版的Dubbo在線程模型上有一些修改，我們以下的分析是以2.5.10為例。

以圖和部分代碼說明Dubbo協(xié)議的調用過程，代碼只寫了一些關鍵部分，使用的是netty3，dubbo線程池無隊列，同步調用，以下代碼包含了Dubbo和Netty的代碼。

整個Dubbo一次調用過程如下：

1.請求入隊

我們通過Dubbo調用一個rpc服務，調用線程其實是把這個請求封裝后放入了一個隊列里。這個隊列是netty的一個隊列，這個隊列的定義如下，是一個Linked隊列，不限長度。

class NioWorker implements Runnable {    ...    private final Queue writeTaskQueue = new LinkedTransferQueue();    ...}

主線程經(jīng)過一系列調用，最終通過NioClientSocketPipelineSink類里的方法把請求放入這個隊列，放入隊列的請求，包含了一個請求ID，這個ID很重要。

2.調用線程等待

入隊后，netty會返回給調用線程一個Future，然后調用線程等待在Future上。這個Future是Dubbo定義的，名字叫DefaultFuture，主調用線程調用DefaultFuture.get(timeout)，等待通知，所以我們看與Dubbo相關的ThreadDump，經(jīng)常會看到線程停在這，這就是在等后臺返回。

public class DubboInvoker<T> extends AbstractInvoker<T> {    ...   @Override    protected Result doInvoke(final Invocation invocation) throws Throwable {         ...         return (Result) currentClient.request(inv, timeout).get(); //currentClient.request(inv, timeout)返回了一個DefaultFuture    }    ...}

我們可以看一下這個DefaultFuture的實現(xiàn)，

public class DefaultFuture implements ResponseFuture {
    private static final Map CHANNELS = new ConcurrentHashMap();    private static final Map FUTURES = new ConcurrentHashMap();
    // invoke id.    private final long id;      //Dubbo請求的id，每個消費者都是一個從0開始的long類型    private final Channel channel;    private final Request request;    private final int timeout;    private final Lock lock = new ReentrantLock();    private final Condition done = lock.newCondition();    private final long start = System.currentTimeMillis();    private volatile long sent;    private volatile Response response;    private volatile ResponseCallback callback;    public DefaultFuture(Channel channel, Request request, int timeout) {        this.channel = channel;        this.request = request;        this.id = request.getId();        this.timeout = timeout > 0 ? timeout : channel.getUrl().getPositiveParameter(Constants.TIMEOUT_KEY, Constants.DEFAULT_TIMEOUT);        // put into waiting map.        FUTURES.put(id, this);    //等待時以id為key把Future放入全局的Future Map中，這樣回復數(shù)據(jù)回來了可以根據(jù)id找到對應的Future通知主線程        CHANNELS.put(id, channel);    }

3.IO線程讀取隊列里的數(shù)據(jù)

這個工作是由netty的IO線程池完成的，也就是NioWorker，對應的類叫NioWorker。它會死循環(huán)的執(zhí)行select，在select中，會一次性把隊列中的寫請求處理完，select的邏輯如下：

public void run() {????for?(;;)?{       ....????????????SelectorUtil.select(selector);
????????????proce***egisterTaskQueue();????????????processWriteTaskQueue();?//先處理隊列里的寫請求            processSelectedKeys(selector.selectedKeys()); //再處理select事件,讀寫都可能有       ....    }}
private void processWriteTaskQueue() throws IOException {    for (;;) {        final Runnable task = writeTaskQueue.poll();//這個隊列就是調用線程把請求放進去的隊列        if (task == null) {            break;        }        task.run(); //寫數(shù)據(jù)        cleanUpCancelledKeys();    }}

4.IO線程把數(shù)據(jù)寫到Socket緩沖區(qū)

這一步很重要，跟我們遇到的性能問題相關，還是NioWorker，也就是上一步的task.run()，它的實現(xiàn)如下：

void writeFromTaskLoop(final NioSocketChannel ch) {    if (!ch.writeSuspended) { //這個地方很重要，如果writeSuspended了，那么就直接跳過這次寫        write0(ch);    }}
private void write0(NioSocketChannel channel) {    ......    final int writeSpinCount = channel.getConfig().getWriteSpinCount(); //netty可配置的一個參數(shù)，默認是16    synchronized (channel.writeLock) {        channel.inWriteNowLoop = true;        for (;;) {            for (int i = writeSpinCount; i > 0; i --) { //每次最多嘗試16次                localWrittenBytes = buf.transferTo(ch);                if (localWrittenBytes != 0) {                    writtenBytes += localWrittenBytes;                    break;????????????????}                if (buf.finished()) {                    break;                }            }
            if (buf.finished()) {                // Successful write - proceed to the next message.                buf.release();                channel.currentWriteEvent = null;                channel.currentWriteBuffer = null;                evt = null;                buf = null;                future.setSuccess();            } else {                // Not written fully - perhaps the kernel buffer is full.                //重點在這，如果寫16次還沒寫完，可能是內核緩沖區(qū)滿了，writeSuspended被設置為true                addOpWrite = true;                channel.writeSuspended = true;                ......            }            ......            if (open) {                if (addOpWrite) {                    setOpWrite(channel);                } else if (removeOpWrite) {                    clearOpWrite(channel);                }            }            ......        }        fireWriteComplete(channel, writtenBytes);    }

正常情況下，隊列中的寫請求要通過processWriteTaskQueue處理掉，但是這些寫請求也同時注冊到了selector上，如果processWriteTaskQueue寫成功，就會刪掉selector上的寫請求。如果Socket的寫緩沖區(qū)滿了，對于NIO，會立刻返回，對于BIO，會一直等待。Netty使用的是NIO，它嘗試16次后，還是不能寫成功，它就把writeSuspended設置為true，這樣接下來的所有寫請求都會被跳過。那什么時候會再寫呢？這時候就得靠selector了，它如果發(fā)現(xiàn)socket可寫，就把這些數(shù)據(jù)寫進去。

關注公眾號：程序猿DD，與一線架構師共成長！

下面是processSelectedKeys里寫的過程，因為它是發(fā)現(xiàn)socket可寫才會寫，所以直接把writeSuspended設為false。

void writeFromSelectorLoop(final SelectionKey k) {        NioSocketChannel ch = (NioSocketChannel) k.attachment();        ch.writeSuspended = false;        write0(ch);    }

5.數(shù)據(jù)從消費者的socket發(fā)送緩沖區(qū)傳輸?shù)教峁┱叩慕邮站彌_區(qū)

這個是操作系統(tǒng)和網(wǎng)卡實現(xiàn)的，應用層的write寫成功了，并不代表對面能收到，當然tcp會通過重傳能機制盡量保證對端收到。

6.服務端IO線程從緩沖區(qū)讀取請求數(shù)據(jù)

這個是服務端的NIO線程實現(xiàn)的，在processSelectedKeys中。

public void run() {????for?(;;)?{        ....????????SelectorUtil.select(selector);
        proce***egisterTaskQueue();        processWriteTaskQueue();        processSelectedKeys(selector.selectedKeys()); //再處理select事件,讀寫都可能有        ....    }}
    private void processSelectedKeys(Set selectedKeys) throws IOException {        for (Iterator i = selectedKeys.iterator(); i.hasNext();) {            SelectionKey k = i.next();            i.remove();            try {                int readyOps = k.readyOps();                if ((readyOps & SelectionKey.OP_READ) != 0 || readyOps == 0) {                    if (!read(k)) {                        // Connection already closed - no need to handle write.                        continue;                    }                }                if ((readyOps & SelectionKey.OP_WRITE) != 0) {                    writeFromSelectorLoop(k);                }            } catch (CancelledKeyException e) {                close(k);            }
            if (cleanUpCancelledKeys()) {                break; // break the loop to avoid ConcurrentModificationException            }        }    }    private boolean read(SelectionKey k) {       ......
            // Fire the event.            fireMessageReceived(channel, buffer);  //讀取完后，最終會調用這個函數(shù)，發(fā)送一個收到信息的事件       ......
    }

7.IO線程把請求交給Dubbo線程池

按配置不同，走的Handler不同，配置dispatch為all，走的handler如下。下面IO線程直接交給一個ExecutorService來處理這個請求，出現(xiàn)了熟悉的報錯“Threadpool is exhausted"，業(yè)務線程池滿時，如果沒有隊列，就會報這個錯。

public class AllChannelHandler extends WrappedChannelHandler {    ......    public void received(Channel channel, Object message) throws RemotingException {        ExecutorService cexecutor = getExecutorService();        try {            cexecutor.execute(new ChannelEventRunnable(channel, handler, ChannelState.RECEIVED, message));        } catch (Throwable t) {            //TODO A temporary solution to the problem that the exception information can not be sent to the opposite end after the thread pool is full. Need a refactoring            //fix The thread pool is full, refuses to call, does not return, and causes the consumer to wait for time out            if(message instanceof Request && t instanceof RejectedExecutionException){                Request request = (Request)message;                if(request.isTwoWay()){                    String msg = "Server side(" + url.getIp() + "," + url.getPort() + ") threadpool is exhausted ,detail msg:" + t.getMessage();                    Response response = new Response(request.getId(), request.getVersion());                    response.setStatus(Response.SERVER_THREADPOOL_EXHAUSTED_ERROR);                    response.setErrorMessage(msg);                    channel.send(response);                    return;                }            }            throw new ExecutionException(message, channel, getClass() + " error when process received event .", t);        }    }    ......}

8.服務端Dubbo線程池處理完請求后，把返回報文放入隊列

線程池會調起下面的函數(shù)

public class HeaderExchangeHandler implements ChannelHandlerDelegate {    ......    Response handleRequest(ExchangeChannel channel, Request req) throws RemotingException {        Response res = new Response(req.getId(), req.getVersion());        ......        // find handler by message class.        Object msg = req.getData();        try {            // handle data.            Object result = handler.reply(channel, msg);   //真正的業(yè)務邏輯類            res.setStatus(Response.OK);            res.setResult(result);        } catch (Throwable e) {            res.setStatus(Response.SERVICE_ERROR);            res.setErrorMessage(StringUtils.toString(e));        }        return res;    }
    public void received(Channel channel, Object message) throws RemotingException {       ......
            if (message instanceof Request) {                // handle request.                Request request = (Request) message;
                    if (request.isTwoWay()) {                        Response response = handleRequest(exchangeChannel, request); //處理業(yè)務邏輯，得到一個Response                        channel.send(response);  //回寫response                    }            }       ......
 }

channel.send(response)最終調用了NioServerSocketPipelineSink里的方法把返回報文放入隊列。

9.服務端IO線程從隊列中取出數(shù)據(jù)

與流程3一樣

10.服務端IO線程把回復數(shù)據(jù)寫入Socket發(fā)送緩沖區(qū)

IO線程寫數(shù)據(jù)的時候，寫入到TCP緩沖區(qū)就算成功了。但是如果緩沖區(qū)滿了，會寫不進去。對于阻塞和非阻塞IO，返回結果不一樣，阻塞IO會一直等，而非阻塞IO會立刻失敗，讓調用者選擇策略。

Netty的策略是嘗試最多寫16次，如果不成功，則暫時停掉IO線程的寫操作，等待連接可寫時再寫，writeSpinCount默認是16，可以通過參數(shù)調整。

for (int i = writeSpinCount; i > 0; i --) {    localWrittenBytes = buf.transferTo(ch);    if (localWrittenBytes != 0) {        writtenBytes += localWrittenBytes;        break;    }    if (buf.finished()) {        break;    } }
    if (buf.finished()) {         // Successful write - proceed to the next message.         buf.release();         channel.currentWriteEvent = null;         channel.currentWriteBuffer = null;         evt = null;         buf = null;         future.setSuccess();     } else {          // Not written fully - perhaps the kernel buffer is full.          addOpWrite = true;          channel.writeSuspended = true;

11.數(shù)據(jù)傳輸

數(shù)據(jù)在網(wǎng)絡上傳輸主要取決于帶寬和網(wǎng)絡環(huán)境。

12.客戶端IO線程把數(shù)據(jù)從緩沖區(qū)讀出

這個過程跟流程6是一樣的

13.IO線程把數(shù)據(jù)交給Dubbo業(yè)務線程池

這一步與流程7是一樣的，這個線程池名字為DubboClientHandler。

14.業(yè)務線程池根據(jù)消息ID通知主線程

先通過HeaderExchangeHandler的received函數(shù)得知是Response，然后調用handleResponse，

public class HeaderExchangeHandler implements ChannelHandlerDelegate {    static void handleResponse(Channel channel, Response response) throws RemotingException {        if (response != null && !response.isHeartbeat()) {            DefaultFuture.received(channel, response);        }    }    public void received(Channel channel, Object message) throws RemotingException {        ......        if (message instanceof Response) {                handleResponse(channel, (Response) message);        }        ......}

DefaultFuture根據(jù)ID獲取Future，通知調用線程

 public static void received(Channel channel, Response response) {         ......         DefaultFuture future = FUTURES.remove(response.getId());         if (future != null) {            future.doReceived(response);         }         ......    }

至此，主線程獲取了返回數(shù)據(jù)，調用結束。

三、影響上述流程的關鍵參數(shù)

協(xié)議參數(shù)

我們在使用Dubbo時，需要在服務端配置協(xié)議，例如

<dubbo:protocol name="dubbo" port="20880" dispatcher="all" threadpool="fixed" threads="2000" />

下面是協(xié)議中與性能相關的一些參數(shù)，在我們的使用場景中，線程池選用了fixed，大小是500，隊列為0，其他都是默認值。

屬性	對應URL參數(shù)	類型	是否必填	缺省值	作用	描述
name		string	必填	dubbo	性能調優(yōu)	協(xié)議名稱
threadpool	threadpool	string	可選	fixed	性能調優(yōu)	線程池類型，可選：fixed/cached。
threads	threads	int	可選	200	性能調優(yōu)	服務線程池大小(固定大小)
queues	queues	int	可選	0	性能調優(yōu)	線程池隊列大小，當線程池滿時，排隊等待執(zhí)行的隊列大小，建議不要設置，當線程池滿時應立即失敗，重試其它服務提供機器，而不是排隊，除非有特殊需求。
iothreads	iothreads	int	可選	cpu個數(shù)+1	性能調優(yōu)	io線程池大小(固定大小)
accepts	accepts	int	可選	0	性能調優(yōu)	服務提供方最大可接受連接數(shù)，這個是整個服務端可以建的最大連接數(shù)，比如設置成2000，如果已經(jīng)建立了2000個連接，新來的會被拒絕，是為了保護服務提供方。
dispatcher	dispatcher	string	可選	dubbo協(xié)議缺省為all	性能調優(yōu)	協(xié)議的消息派發(fā)方式，用于指定線程模型，比如：dubbo協(xié)議的all, direct, message, execution, connection等。這個主要牽涉到IO線程池和業(yè)務線程池的分工問題，一般情況下，讓業(yè)務線程池處理建立連接、心跳等，不會有太大影響。
payload	payload	int	可選	8388608(=8M)	性能調優(yōu)	請求及響應數(shù)據(jù)包大小限制，單位：字節(jié)。這個是單個報文允許的最大長度，Dubbo不適合報文很長的請求，所以加了限制。
buffer	buffer	int	可選	8192	性能調優(yōu)	網(wǎng)絡讀寫緩沖區(qū)大小。注意這個不是TCP緩沖區(qū)，這個是在讀寫網(wǎng)絡報文時，應用層的Buffer。
codec	codec	string	可選	dubbo	性能調優(yōu)	協(xié)議編碼方式
serialization	serialization	string	可選	dubbo協(xié)議缺省為hessian2，rmi協(xié)議缺省為java，http協(xié)議缺省為json	性能調優(yōu)	協(xié)議序列化方式，當協(xié)議支持多種序列化方式時使用，比如：dubbo協(xié)議的dubbo,hessian2,java,compactedjava，以及http協(xié)議的json等
transporter	transporter	string	可選	dubbo協(xié)議缺省為netty	性能調優(yōu)	協(xié)議的服務端和客戶端實現(xiàn)類型，比如：dubbo協(xié)議的mina,netty等，可以分拆為server和client配置
server	server	string	可選	dubbo協(xié)議缺省為netty，http協(xié)議缺省為servlet	性能調優(yōu)	協(xié)議的服務器端實現(xiàn)類型，比如：dubbo協(xié)議的mina,netty等，http協(xié)議的jetty,servlet等
client	client	string	可選	dubbo協(xié)議缺省為netty	性能調優(yōu)	協(xié)議的客戶端實現(xiàn)類型，比如：dubbo協(xié)議的mina,netty等
charset	charset	string	可選	UTF-8	性能調優(yōu)	序列化編碼
heartbeat	heartbeat	int	可選	0	性能調優(yōu)	心跳間隔，對于長連接，當物理層斷開時，比如拔網(wǎng)線，TCP的FIN消息來不及發(fā)送，對方收不到斷開事件，此時需要心跳來幫助檢查連接是否已斷開

服務參數(shù)

針對每個Dubbo服務，都會有一個配置，全部的參數(shù)配置在這：http://dubbo.apache.org/zh-cn/docs/user/references/xml/dubbo-service.html。

我們關注幾個與性能相關的。在我們的使用場景中，重試次數(shù)設置成了0，集群方式用的failfast，其他是默認值。

屬性	對應URL參數(shù)	類型	是否必填	缺省值	作用	描述	兼容性
delay	delay	int	可選	0	性能調優(yōu)	延遲注冊服務時間(毫秒) ，設為-1時，表示延遲到Spring容器初始化完成時暴露服務	1.0.14以上版本
timeout	timeout	int	可選	1000	性能調優(yōu)	遠程服務調用超時時間(毫秒)	2.0.0以上版本
retries	retries	int	可選	2	性能調優(yōu)	遠程服務調用重試次數(shù)，不包括第一次調用，不需要重試請設為0	2.0.0以上版本
connections	connections	int	可選	1	性能調優(yōu)	對每個提供者的最大連接數(shù)，rmi、http、hessian等短連接協(xié)議表示限制連接數(shù)，dubbo等長連接協(xié)表示建立的長連接個數(shù)	2.0.0以上版本
loadbalance	loadbalance	string	可選	random	性能調優(yōu)	負載均衡策略，可選值：random,roundrobin,leastactive，分別表示：隨機，輪詢，最少活躍調用	2.0.0以上版本
async	async	boolean	可選	false	性能調優(yōu)	是否缺省異步執(zhí)行，不可靠異步，只是忽略返回值，不阻塞執(zhí)行線程	2.0.0以上版本
weight	weight	int	可選		性能調優(yōu)	服務權重	2.0.5以上版本
executes	executes	int	可選	0	性能調優(yōu)	服務提供者每服務每方法最大可并行執(zhí)行請求數(shù)	2.0.5以上版本
proxy	proxy	string	可選	javassist	性能調優(yōu)	生成動態(tài)代理方式，可選：jdk/javassist	2.0.5以上版本
cluster	cluster	string	可選	failover	性能調優(yōu)	集群方式，可選：failover/failfast/failsafe/failback/forking	2.0.5以上版本

這次擁堵的主要原因，應該就是服務的connections設置的太小，dubbo不提供全局的連接數(shù)配置，只能針對某一個交易做個性化的連接數(shù)配置。

四、連接數(shù)與Socket緩沖區(qū)對性能影響的實驗

通過簡單的Dubbo服務，驗證一下連接數(shù)與緩沖區(qū)大小對傳輸性能的影響。

我們可以通過修改系統(tǒng)參數(shù)，調節(jié)TCP緩沖區(qū)的大小。

在 /etc/sysctl.conf 修改如下內容， tcp_rmem是發(fā)送緩沖區(qū)，tcp_wmem是接收緩沖區(qū)，三個數(shù)值表示最小值，默認值和最大值，我們可以都設置成一樣。

net.ipv4.tcp_rmem = 4096 873800 16777216net.ipv4.tcp_wmem = 4096 873800 16777216

然后執(zhí)行sysctl –p 使之生效。

服務端代碼如下，接受一個報文，然后返回兩倍的報文長度，隨機sleep 0-300ms，所以均值應該是150ms。服務端每10s打印一次tps和響應時間，這里的tps是指完成函數(shù)調用的tps，而不涉及傳輸，響應時間也是這個函數(shù)的時間。

   //服務端實現(xiàn)   public String sayHello(String name) {        counter.getAndIncrement();        long start = System.currentTimeMillis();        try {            Thread.sleep(rand.nextInt(300));        } catch (InterruptedException e) {        }        String result = "Hello " + name + name  + ", response form provider: " + RpcContext.getContext().getLocalAddress();        long end = System.currentTimeMillis();        timer.getAndAdd(end-start);        return result;    }

客戶端起N個線程，每個線程不停的調用Dubbo服務，每10s打印一次qps和響應時間，這個qps和響應時間是包含了網(wǎng)絡傳輸時間的。

        for(int i = 0; i < N; i ++) {            threads[i] = new Thread(new Runnable() {                @Override                public void run() {                    while(true) {                        Long start = System.currentTimeMillis();                        String hello = service.sayHello(z);                        Long end = System.currentTimeMillis();                        totalTime.getAndAdd(end-start);                        counter.getAndIncrement();                    }                }});            threads[i].start();        }

通過ss -it命令可以看當前tcp socket的詳細信息，包含待對端回復ack的數(shù)據(jù)Send-Q，最大窗口cwnd，rtt(round trip time)等。

(base) niuxinli@ubuntu:~$ ss -itState                            Recv-Q                        Send-Q                                                       Local Address:Port                                                          Peer Address:PortESTAB                            0                             36                                                             192.168.1.7:ssh                                                            192.168.1.4:58931                            cubic wscale:8,2 rto:236 rtt:33.837/8.625 ato:40 mss:1460 pmtu:1500 rcvmss:1460 advmss:1460 cwnd:10 bytes_acked:559805 bytes_received:54694 segs_out:2754 segs_in:2971 data_segs_out:2299 data_segs_in:1398 send 3.5Mbps pacing_rate 6.9Mbps delivery_rate 44.8Mbps busy:36820ms unacked:1 rcv_rtt:513649 rcv_space:16130 rcv_ssthresh:14924 minrtt:0.112ESTAB                            0                             0                                                              192.168.1.7:36666                                                          192.168.1.7:2181                             cubic wscale:7,7 rto:204 rtt:0.273/0.04 ato:40 mss:33344 pmtu:65535 rcvmss:536 advmss:65483 cwnd:10 bytes_acked:2781 bytes_received:3941 segs_out:332 segs_in:170 data_segs_out:165 data_segs_in:165 send 9771.1Mbps lastsnd:4960 lastrcv:4960 lastack:4960 pacing_rate 19497.6Mbps delivery_rate 7621.5Mbps app_limited busy:60ms rcv_space:65535 rcv_ssthresh:66607 minrtt:0.035ESTAB                            0                             27474                                                          192.168.1.7:20880                                                          192.168.1.5:60760                            cubic wscale:7,7 rto:204 rtt:1.277/0.239 ato:40 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:625 ssthresh:20 bytes_acked:96432644704 bytes_received:49286576300 segs_out:68505947 segs_in:36666870 data_segs_out:67058676 data_segs_in:35833689 send 5669.5Mbps pacing_rate 6801.4Mbps delivery_rate 627.4Mbps app_limited busy:1340536ms rwnd_limited:400372ms(29.9%) sndbuf_limited:433724ms(32.4%) unacked:70 retrans:0/5 rcv_rtt:1.308 rcv_space:336692 rcv_ssthresh:2095692 notsent:6638 minrtt:0.097

通過netstat -nat也能查看當前tcp socket的一些信息，比如Recv-Q, Send-Q。

(base) niuxinli@ubuntu:~$ netstat -natActive Internet connections (servers and established)Proto Recv-Q Send-Q Local Address           Foreign Address         Statetcp        0      0 0.0.0.0:20880           0.0.0.0:*               LISTENtcp        0     36 192.168.1.7:22          192.168.1.4:58931       ESTABLISHEDtcp        0      0 192.168.1.7:36666       192.168.1.7:2181        ESTABLISHEDtcp        0  65160 192.168.1.7:20880       192.168.1.5:60760       ESTABLISHED

可以看以下Recv-Q和Send-Q的具體含義：

 Recv-Q       Established: The count of bytes not copied by the user program connected to this socket.
   Send-Q       Established: The count of bytes not acknowledged by the remote host.

Recv-Q是已經(jīng)到了接受緩沖區(qū)，但是還沒被應用代碼讀走的數(shù)據(jù)。Send-Q是已經(jīng)到了發(fā)送緩沖區(qū)，但是對方還沒有回復Ack的數(shù)據(jù)。這兩種數(shù)據(jù)正常一般不會堆積，如果堆積了，可能就有問題了。

第一組實驗：單連接，改變TCP緩沖區(qū)

結果：

繼續(xù)調大緩沖區(qū)

我們用netstat或者ss命令可以看到當前的socket情況，下面的第二列是Send-Q大小，是寫入緩沖區(qū)還沒有被對端確認的數(shù)據(jù)，發(fā)送緩沖區(qū)最大時64k左右，說明緩沖區(qū)不夠用。

繼續(xù)增大緩沖區(qū)，到4M，我們可以看到，響應時間進一步下降，但是還是在傳輸上浪費了不少時間，因為服務端應用層沒有壓力。

服務端和客戶端的TCP情況如下，緩沖區(qū)都沒有滿

服務端

客戶端

這個時候，再怎么調大TCP緩沖區(qū)，也是沒用的，因為瓶頸不在這了，而在于連接數(shù)。因為在Dubbo中，一個連接會綁定到一個NioWorker線程上，讀寫都由這一個連接完成，傳輸?shù)乃俣瘸^了單個線程的讀寫能力，所以我們看到在客戶端，大量的數(shù)據(jù)擠壓在接收緩沖區(qū)，沒被讀走，這樣對端的傳輸速率也會慢下來。

第二組實驗：多連接，固定緩沖區(qū)

服務端的純業(yè)務函數(shù)響應時間很穩(wěn)定，在緩沖區(qū)較小的時候，調大連接數(shù)雖然能讓時間降下來，但是并不能到最優(yōu)，所以緩沖區(qū)不能設置太小，Linux一般默認是4M，在4M的時候，4個連接基本上已經(jīng)能把響應時間降到最低了。

# 結論

要想充分利用網(wǎng)絡帶寬，緩沖區(qū)不能太小，如果太小有可能一次傳輸?shù)膱笪木痛笥诹司彌_區(qū)，嚴重影響傳輸效率。但是太大了也沒有用，還需要多個連接數(shù)才能夠充分利用CPU資源，連接數(shù)起碼要超過CPU核數(shù)。

推薦閱讀

代碼對比工具，我就用這6個
分享我常用的5個免費的在線 SQL 數(shù)據(jù)庫環(huán)境，簡直太方便了！
Spring Boot 三招組合拳，手把手教你打出優(yōu)雅的后端接口
MySQL 5.7 vs 8.0，你選那個？網(wǎng)友：我繼續(xù)原地踏步~

最后，推薦給大家一個有趣有料的公眾號：寫代碼的渣渣鵬，7年老程序員教你寫bug,回復面試|資源送一你整套開發(fā)筆記有驚喜哦

掃碼關注

突發(fā)流量引發(fā)的Dubbo擁堵，該怎么辦？

一、背景