unsigned int srv_dynamic_maxconn(const struct server *s,struct session* session)

{

unsigned int max;

if (s->proxy->beconn >= s->proxy->fullconn)

{

/* no fullconn or proxy is full */

max = s->maxconn;

}

else if (s->minconn == s->maxconn)

{    

    /* static limit */

max = s->maxconn;

}

else 

{

       max = MAX(s->minconn,

       s->proxy->beconn * s->maxconn / s->proxy->fullconn);

}

if ((s->state & SRV_WARMINGUP) &&

    now.tv_sec < s->last_change + s->slowstart &&

    now.tv_sec >= s->last_change) {

unsigned int ratio;

ratio = 100 * (now.tv_sec - s->last_change) / s->slowstart;

max = MAX(1, max * ratio / 100);

}

return max;

}

于是在此段代碼中添加日志，發現在螞蟻窩環境下，每次此函數都返回1.

于是問題就知道出在什么地方了，這里返回1，導致每次對于某個后端服務器來說，

第一個請求建立連接會被響應，而后續的2,3.。。都被拒絕。

再查看日志，完全驗證了這一點。

4 解決方案

既然知道了問題所在，那么怎么解決？

必然是通過此函數的邏輯來解決。

查看srv_dynamic_maxconn函數，發現如果在配置中可以有2種方法解決

1 將minconn設置為較大的一個參數

2直接設置為minconn與maxconn一樣，徹底去掉最小限制，對于并發量按照maxconn來配置。

針對第2種情況，代碼中可以看到

也就是如果二者大小一樣的話，max就返回s->maxconn。這樣也沒有問題。

5 與HAProxy作者的郵件交流

既然是開源軟件，那么就可以直接跟作者交流。

下面是跟作者的郵件交流。

5.1 發送郵件描述問題

5.2 對方回復

5.3 再次發送驗證答案

于是發送自己的答案過去，看對方對我們的解決方案的評價，同時不忘熱情贊美對方的軟件之流行度。

5.4 對方的最終回應

也就是說，作者認為直接去掉minconn參數更好，于是我們在haproxy.cfg的配置中去掉了這個參數，通過日志打印，minconn的值會等于maxconn參數，也就是走了static limit這個分支。

至此問題得以解決,對HAProxy的理解比之前更進一步。

6 后記

1 碰到問題，迎難而上，尤其是在有源碼的情況下，直接debug或者看源碼，肯定可以解決問題。一般在linux中c采用gdb,java采用jdb都可逐行跟蹤，非常方便準確！

2 開源軟件，網上有很多別人踩過的坑，可以嘗試搜索是否已經有解決方案。

3 相對于所解決的問題，方法論非常重要，這個也需要經驗的積累，比如本文中HAProxy問題的定位其實就在于connect(...) api的入口定位，整理出調用棧，然后添加日志逐步定位問題。