spymemcached 的 useNagle 問題與 TCP/IP延遲發送資料

先說一下結論。

如果你沒有特意在 spymemcached 的 client bean definition 裡配置 useNagleAlgorithm 屬性為 True，

那麼 預設 spymemcached 是不啟用 Nagle 演算法的。

所以預設情況下不會引發恨少在《libmemcached的MEMCACHED_MAX_BUFFER問題》一文中提及的“shell指令碼set 1000次8KB的item，只要3s左右，平均需要3ms。而C++版本則需要39s左右，平均耗時39ms……發現8KB的資料需要發送兩次，兩次write都是非常快的，但是等memcached返回時用了很多時間，主要的時間就耗費在這個地方”現象。咱們業務中心可以排除這個嫌疑。  什麼是 Nagle 演算法？『

TCP/IP協議中，無論發送多少資料，總是要在資料前面加上協議頭，同時，對方接收到資料，也需要發送ACK表示確認。為了儘可能地利用網路頻寬，TCP總是希望儘可能地發送足夠大的資料。（一個串連會設定MSS參數，因此，TCP/IP希望每次都能夠以MSS尺寸的資料區塊來發送資料）。Nagle演算法就是為了儘可能發送大塊資料，避免網路中充斥著許多小資料區塊。

Nagle演算法的基本定義是 任意時刻，最多隻能有一個未被確認的小段。 所謂“小段”，指的是小於MSS尺寸的資料區塊，所謂“未被確認”，是指一個資料區塊發送出去後，沒有收到對方發送的ACK確認該資料已收到。

        Nagle演算法的規則（可參考tcp_output.c檔案裡tcp_nagle_check函數注釋）： 

      （1）如果包長度達到MSS，則允許發送；

      （2）如果該包含有FIN，則允許發送；

      （3）設定了TCP_NODELAY選項，則允許發送；

      （4）未設定TCP_CORK選項時，若所有發出去的小資料包（包長度小於MSS）均被確認，則允許發送； 

      （5）上述條件都未滿足，但發生了逾時（一般為200ms），則立即發送。』——糊塗視窗綜合症和Nagle演算法  spymemcached 預設不啟用 Nagle 演算法/net/spy/memcached/ConnectionFactoryBuilder.java 中定義如下：/** * Builder for more easily configuring a ConnectionFactory. */public class ConnectionFactoryBuilder {

  protected boolean useNagle = false;

……

  public ConnectionFactoryBuilder(ConnectionFactory cf) {

……

    setUseNagleAlgorithm(cf.useNagleAlgorithm());  }  /** * Set to true if you'd like to enable the Nagle algorithm. */  public ConnectionFactoryBuilder setUseNagleAlgorithm(boolean to) {    useNagle = to;    return this;  }然後，轉到 MemcachedConnection.java，說到底還是調用 socket 的 setTcpNoDelay 方法：  protected List<MemcachedNode> createConnections(……      ch.socket().setTcpNoDelay(!this.connectionFactory.useNagleAlgorithm());  通過 bean definition 可設定 useNagleAlgorithm參考 SpringIntegration 文檔，spring 裡配置如下：

<beanid="memcachedClient"class="net.spy.memcached.spring.MemcachedClientFactoryBean">……

   <propertyname="useNagleAlgorithm"value="false"/>
  </bean>

 p.s.:1）另一個常用的 memcached java client——xmemcached 從1.3.6版本開始也預設禁用了 Nagle 演算法。

2）mongo-java-driver 預設也禁用 Nagle 演算法（DBPort.java 63行）。

參考資源：1）網路編程中Nagle演算法和Delayed ACK的測試2）火丁，2012，Memcached二三事兒；3）2009， Issue 88:  Turn off TCP nagle can hugely improve performance；

 

 

1）55最佳實務系列：MongoDB最佳實務 (2012-12-15 15:48)
2）55最佳實務系列：Logging最佳實務 (2012-12-15 16:43)3）最佳實務系列：前端代碼標準和最佳實務 (2012-12-19 23:33) 1）電商課題I：Throttle Limits for calls/requests in a clustered environment (2012-11-17 22:14)

2）電商課題V：分布式鎖 (2012-11-17 22:16)

3）電商課題：cookie防篡改 (2012-11-17 22:24)4）電商課題VI：分布式Session (2012-11-17 22:30)

5）電商課題：RBAC許可權控制 (2012-11-17 22:47)

6）電商課題：等冪性 (2012-11-22 23:52)

7）電商課題：用戶端的IP地址偽造、CDN、反向 Proxy、擷取的那些事兒 (2012-09-19 01:17)

8）電商課題：對付秒殺器等惡意訪問行為的簡單梳理 (2012-09-18 03:51)

9）電商課題VII：支付交易一般性準則 (2012-12-14 01:38)

贈圖幾枚：