前天ksearch性能壓測過程中發(fā)現(xiàn)一個很奇怪的問題，跟了3天，case做了無數(shù)個，終于發(fā)現(xiàn)問題所在，還是KFC（KuaFu Communication）的問題。然后想起來，去年實時搜索上線前夕，也遇到一個很奇怪的問題，最后定位出來也是KFC的問題，異常郁悶，所以這里記錄一下。

ksearch的服務(wù)框架：search和merge兩種角色，search負責真正的存儲和檢索，通過行結(jié)構(gòu)做災(zāi)備，列結(jié)構(gòu)獲得大數(shù)據(jù)量和高QPS；merge對外提供服務(wù)，對內(nèi)轉(zhuǎn)發(fā)請求給相應(yīng)列的search機器；search和merge之間的網(wǎng)絡(luò)和角色，是通過kfc管理的。search的每一列負責同一個key的請求，merge通過key_send轉(zhuǎn)發(fā)請求到相應(yīng)search機器。kfc對我們來說是一套黑盒系統(tǒng)，只是聽老大說很nb，很多部門都在用；使用過程中碰到了很多蛋疼的問題。以后有這種涉及到性能的大型系統(tǒng)，千萬不要信黑盒系統(tǒng)，不管別人說它多么nb。

case 1： 2行6列search，merge復(fù)用第一行的前兩臺機器

現(xiàn)象：通過merge壓測時，如果把query落在單獨一列，不管是高并發(fā)還是低并發(fā)，由于search服務(wù)能力很強，可以很輕松把merge網(wǎng)絡(luò)壓滿，達到10K的qps；用abench -r壓也可以輕松達到8K以上沒有異常。但是如果query落到所有列上，低并發(fā)情況下，可以達到10K；如果用高并發(fā)壓，發(fā)現(xiàn)qps只能達到5K左右；用abench -r壓2K的qps都會有很多超時，和預(yù)期相差很大。看merge機器，不管是進程還是系統(tǒng)，都遠遠沒有達到瓶頸；而且search機器也很空閑。由于下周就要上線，相當操蛋。

針對這個問題，我們做了以下實驗：

1.? 只壓到兩列的query，結(jié)果跟壓全列query一樣，說明不是機器規(guī)模問題。

2.? 調(diào)整query返回結(jié)果大小，發(fā)現(xiàn)高并發(fā)下qps跟返回結(jié)果大小成反比，即返回結(jié)果越小，qps越高；而實際上返回結(jié)構(gòu)大小，search處理時間幾乎不會變化。 說明還是網(wǎng)絡(luò)的問題。

3. 分析log發(fā)現(xiàn)，不管高并發(fā)還是低并發(fā)，search機器處理query的平均時間沒有變化，但merge機器觀察到search的latency卻有很大變化。網(wǎng)絡(luò)通信我們用的是kfc，說明問題出在kfc身上。

還有其他一些，不一一列了，最后確認是同一臺機器復(fù)用search和merge，觸發(fā)了kfc的性能問題；通過調(diào)整系統(tǒng)部署解決。

case 2: 2行22列，3臺merge

現(xiàn)象：merge總是觀察到批量超時，每次一有query超時就超一批，對超時query分析發(fā)現(xiàn)，每一批中一般只有一個大賣家，其他都是小賣家。大賣家超時是可以預(yù)期的，小賣家超時卻沒辦法解釋。

case做了一大堆，糾結(jié)到最后發(fā)現(xiàn)是因為，kfc分發(fā)消息時使用Round-Robin方式，假設(shè)有10個server提供服務(wù)，來了1000個query，他會為RR的為每個server分100個query，而不是哪個server閑著就分配給哪個。這樣就有問題了，如果有一個大賣家堵住了一個server，其他的query就在他后面排隊，等到第一個大賣家超時，后面堵著的所有賣家都超時了。

總結(jié)

以上是生活随笔為你收集整理的ksearch系统开发过程中遇到的KFC性能问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。