作者：nxlhero
來源：https://blog.51cto.com/nxlhero/2515849

文章內容結構

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

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

第三部分介紹整個呼叫程序中與性能相關的一些引數，

第四部分通過調整連接數和TCP緩沖區觀察Dubbo的性能，

一、背景

生產擁堵回顧

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

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

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

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

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

(3)通過監控工具統計的每秒進入Dubbo業務執行緒池的請求數，在擁堵時，時而是0，時而特別大，在日間正常的時候，這個值不存在為0的時候，

事故原因猜測

當時其他指標沒有檢測到例外，也沒有打Dump，我們通過分析這些現象以及我們的Dubbo配置，猜測是在網路上發生了擁堵，而影響擁堵的關鍵引數就是Dubbo協議的連接數，我們默認使用了單個連接，但是消費者數量較少，沒能充分把網路資源利用起來，

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

Dubbo 預設協議采用單一長連接和 NIO 異步通訊，適合于小資料量大并發的服務呼叫，以及服務消費者機器數遠大于服務提供者機器數的情況，

反之，Dubbo 預設協議不適合傳送大資料量的服務，比如傳檔案，傳視頻等，除非請求量很低，

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

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

為什么要消費者比提供者個數多?

因 dubbo 協議采用單一長連接，假設網路為千兆網卡，根據測驗經驗資料每條連接最多只能壓滿 7MByte(不同的環境可能不一樣，供參考)，理論上 1 個服務提供者需要 20 個服務消費者才能壓滿網卡，

為什么不能傳大包?

因 dubbo 協議采用單一長連接，如果每次請求的資料包大小為 500KByte，假設網路為千兆網卡，每條連接最大 7MByte(不同的環境可能不一樣，供參考)，單個服務提供者的 TPS(每秒處理事務數)最大為：128MByte / 500KByte = 262，單個消費者呼叫單個服務提供者的 TPS(每秒處理事務數)最大為：7MByte / 500KByte = 14，如果能接受，可以考慮使用，否則網路將成為瓶頸，

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

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

因為我們的消費者數量和提供者數量都不多，所以很可能是連接數不夠，導致網路傳輸出現了瓶頸，以下我們通過詳細分析Dubbo協議和一些實驗來驗證我們的猜測，

二、Dubbo通信流程詳解

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

以圖和部分代碼說明Dubbo協議的呼叫程序，代碼只寫了一些關鍵部分，使用的是netty3，dubbo執行緒池無佇列，同步呼叫，以下代碼包含了Dubbo和Netty的代碼，

整個Dubbo一次呼叫程序如下：

1.請求入隊

我們通過Dubbo呼叫一個rpc服務，呼叫執行緒其實是把這個請求封裝后放入了一個佇列里，這個佇列是netty的一個佇列，這個佇列的定義如下，是一個Linked佇列，不限長度，

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

主執行緒經過一系列呼叫，最終通過NioClientSocketPipelineSink類里的方法把請求放入這個佇列，放入佇列的請求，包含了一個請求ID，這個ID很重要，

2.呼叫執行緒等待

入隊后，netty會回傳給呼叫執行緒一個Future，然后呼叫執行緒等待在Future上，這個Future是Dubbo定義的，名字叫DefaultFuture，主呼叫執行緒呼叫DefaultFuture.get(timeout)，等待通知，所以我們看與Dubbo相關的ThreadDump，經常會看到執行緒停在這，這就是在等后臺回傳，

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的實作，

public class DefaultFuture implements ResponseFuture {

    private static final Map<Long, Channel> CHANNELS = new ConcurrentHashMap<Long, Channel>();
    private static final Map<Long, DefaultFuture> FUTURES = new ConcurrentHashMap<Long, DefaultFuture>();

    // 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中，這樣回復資料回來了可以根據id找到對應的Future通知主執行緒
        CHANNELS.put(id, channel);
    }

3.IO執行緒讀取佇列里的資料

這個作業是由netty的IO執行緒池完成的，也就是NioWorker，對應的類叫NioWorker，它會死回圈的執行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(); //寫資料
        cleanUpCancelledKeys();
    }
}

4.IO執行緒把資料寫到Socket緩沖區

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

void writeFromTaskLoop(final NioSocketChannel ch) {
    if (!ch.writeSuspended) { //這個地方很重要，如果writeSuspended了，那么就直接跳過這次寫
        write0(ch);
    }
}
private void write0(NioSocketChannel channel) {
    ......
    final int writeSpinCount = channel.getConfig().getWriteSpinCount(); //netty可配置的一個引數，默認是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次還沒寫完，可能是內核緩沖區滿了，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的寫緩沖區滿了，對于NIO，會立刻回傳，對于BIO，會一直等待，Netty使用的是NIO，它嘗試16次后，還是不能寫成功，它就把writeSuspended設定為true，這樣接下來的所有寫請求都會被跳過，那什么時候會再寫呢？這時候就得靠selector了，它如果發現socket可寫，就把這些資料寫進去，

下面是processSelectedKeys里寫的程序，因為它是發現socket可寫才會寫，所以直接把writeSuspended設為false，

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

5.資料從消費者的socket發送緩沖區傳輸到提供者的接識訓沖區

這個是作業系統和網卡實作的，應用層的write寫成功了，并不代表對面能收到，當然tcp會通過重傳能機制盡量保證對端收到，

6.服務端IO執行緒從緩沖區讀取請求資料

這個是服務端的NIO執行緒實作的，在processSelectedKeys中，

public void run() {
    for (;;) {
       ....
            SelectorUtil.select(selector);

            proce***egisterTaskQueue();
            processWriteTaskQueue();
            processSelectedKeys(selector.selectedKeys()); //再處理select事件,讀寫都可能有
       ....
    }
}
private void processSelectedKeys(Set<SelectionKey> selectedKeys) throws IOException {
    for (Iterator<SelectionKey> 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);  //讀取完后，最侄訓呼叫這個函式，發送一個收到資訊的事件
   ......

}

7.IO執行緒把請求交給Dubbo執行緒池

按配置不同，走的Handler不同，配置dispatch為all，走的handler如下，下面IO執行緒直接交給一個ExecutorService來處理這個請求，出現了熟悉的報錯“Threadpool is exhausted"，業務執行緒池滿時，如果沒有佇列，就會報這個錯，

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執行緒池處理完請求后，把回傳報文放入佇列

執行緒池會調起下面的函式

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);   //真正的業務邏輯類
        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); //處理業務邏輯，得到一個Response
                    channel.send(response);  //回寫response
                }
        }
   ......

}

channel.send(response)最終呼叫了NioServerSocketPipelineSink里的方法把回傳報文放入佇列，

9.服務端IO執行緒從佇列中取出資料

與流程3一樣

10.服務端IO執行緒把回復資料寫入Socket發送緩沖區

IO執行緒寫資料的時候，寫入到TCP緩沖區就算成功了，但是如果緩沖區滿了，會寫不進去，對于阻塞和非阻塞IO，回傳結果不一樣，阻塞IO會一直等，而非阻塞IO會立刻失敗，讓呼叫者選擇策略，

Netty的策略是嘗試最多寫16次，如果不成功，則暫時停掉IO執行緒的寫操作，等待連接可寫時再寫，writeSpinCount默認是16，可以通過引數調整，

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.資料傳輸

資料在網路上傳輸主要取決于帶寬和網路環境，

12.客戶端IO執行緒把資料從緩沖區讀出

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

13.IO執行緒把資料交給Dubbo業務執行緒池

這一步與流程7是一樣的，這個執行緒池名字為DubboClientHandler，

14.業務執行緒池根據訊息ID通知主執行緒

先通過HeaderExchangeHandler的received函式得知是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根據ID獲取Future，通知呼叫執行緒

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

至此，主執行緒獲取了回傳資料，呼叫結束，

三、影響上述流程的關鍵引數

協議引數

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

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

下面是協議中與性能相關的一些引數，在我們的使用場景中，執行緒池選用了fixed，大小是500，佇列為0，其他都是默認值，

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

服務引數

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

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

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

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

四、連接數與Socket緩沖區對性能影響的實驗

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

我們可以通過修改系統引數，調節TCP緩沖區的大小，

在 /etc/sysctl.conf 修改如下內容， tcp_rmem是發送緩沖區，tcp_wmem是接識訓沖區，三個數值表示最小值，默認值和最大值，我們可以都設定成一樣，

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

然后執行sysctl –p 使之生效，

服務端代碼如下，接受一個報文，然后回傳兩倍的報文長度，隨機sleep 0-300ms，所以均值應該是150ms，服務端每10s列印一次tps和回應時間，這里的tps是指完成函式呼叫的tps，而不涉及傳輸，回應時間也是這個函式的時間，

   //服務端實作
   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和回應時間是包含了網路傳輸時間的，

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的資料Send-Q，最大視窗cwnd，rtt(round trip time)等，

(base) niuxinli@ubuntu:~$ ss -it
State                            Recv-Q                        Send-Q                                                       Local Address:Port                                                          Peer Address:Port
ESTAB                            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.112
ESTAB                            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.035
ESTAB                            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 -nat
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:20880           0.0.0.0:*               LISTEN
tcp        0     36 192.168.1.7:22          192.168.1.4:58931       ESTABLISHED
tcp        0      0 192.168.1.7:36666       192.168.1.7:2181        ESTABLISHED
tcp        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是已經到了接受緩沖區，但是還沒被應用代碼讀走的資料，Send-Q是已經到了發送緩沖區，但是對方還沒有回復Ack的資料，這兩種資料正常一般不會堆積，如果堆積了，可能就有問題了，

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

結果：

繼續調大緩沖區

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

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

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

服務端

客戶端

這個時候，再怎么調大TCP緩沖區，也是沒用的，因為瓶頸不在這了，而在于連接數，因為在Dubbo中，一個連接會系結到一個NioWorker執行緒上，讀寫都由這一個連接完成，傳輸的速度超過了單個執行緒的讀寫能力，所以我們看到在客戶端，大量的資料擠壓在接識訓沖區，沒被讀走，這樣對端的傳輸速率也會慢下來，

第二組實驗：多連接，固定緩沖區

服務端的純業務函式回應時間很穩定，在緩沖區較小的時候，調大連接數雖然能讓時間降下來，但是并不能到最優，所以緩沖區不能設定太小，Linux一般默認是4M，在4M的時候，4個連接基本上已經能把回應時間降到最低了，

結論

要想充分利用網路帶寬，緩沖區不能太小，如果太小有可能一次傳輸的報文就大于了緩沖區，嚴重影響傳輸效率，但是太大了也沒有用，還需要多個連接數才能夠充分利用CPU資源，連接數起碼要超過CPU核數，

近期熱文推薦：

1.Java 15 正式發布， 14 個新特性，重繪你的認知！！

2.終于靠開源專案弄到 IntelliJ IDEA 激活碼了，真香！

3.我用 Java 8 寫了一段邏輯，同事直呼看不懂，你試試看，，

4.吊打 Tomcat ，Undertow 性能很炸！！

5.《Java開發手冊（嵩山版）》最新發布，速速下載！

覺得不錯，別忘了隨手點贊+轉發哦！

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/236380.html

標籤：其他

上一篇：精盡Spring MVC原始碼分析 - HandlerAdapter 組件（一）之 HandlerAdapter

下一篇：SpringBoot中的條件注解底層是這樣實作的，你知道嗎？

一次突發流量引起的 Dubbo 服務擁堵！