前言

erlang的httpc是官方自帶的http請(qǐng)求工具, 是一個(gè)體感上很好用的工具（其實(shí)是我沒用過其他工具），前不久，一位大佬離職的時(shí)候就告誡過，使用一個(gè)工具，一定不能直接使用默認(rèn)的參數(shù)，這不，問題就出現(xiàn)了。
(httpc文檔)

問題

有一個(gè)服務(wù)，提供了多個(gè)接口，其中，有部分接口涉及到輪詢，因此響應(yīng)時(shí)間有可能非常非常長。而另一方面，其他正常接口的反應(yīng)時(shí)間是很快的。然而實(shí)際使用的時(shí)候，卻觀察到，本應(yīng)很快返回的接口會(huì)有一定的延時(shí)，在pinpoint的監(jiān)控下可以看到，服務(wù)有時(shí)候會(huì)等待一定的時(shí)間，最長等待了二十多秒。

定位

問題的出現(xiàn)就在于httpc中。我使用了httpc訪問了上文描述的接口，配置都使用的是默認(rèn)的。而httpc的options里有一個(gè)參數(shù)，max_keep_alive_length

MaxKeepAlive = integer()
Maximum number of outstanding requests on the same connection to a host. Default is 5.

這個(gè)參數(shù)的含義是, 根據(jù) HTTP/1.1的協(xié)議, 我們會(huì)復(fù)用連接（減少握手消耗）, 在這樣一條連接上，最多同時(shí)支持五條請(qǐng)求。然而這五條請(qǐng)求只能按照次序返回，如果前面的請(qǐng)求花費(fèi)了很多時(shí)間, 那么后面的請(qǐng)求就必須等待，直到前面的完成。這就是這個(gè)現(xiàn)象出現(xiàn)的原因。

解決方案

在服務(wù)啟動(dòng)的地方，設(shè)置下這個(gè)參數(shù)

httpc:set_options([{max_keep_alive_length, 0}])

其他

另外還有一些參數(shù), 比如說 max_sessions, 釋義是對(duì)單個(gè)host允許的最大連接數(shù)，但是即使為0, 連接仍然會(huì)被復(fù)用，這個(gè)參數(shù)只是一個(gè)軟性的限制，100和0的差距并不大。