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

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

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

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

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

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

2.? 調整query返回結果大小，發現高并發下qps跟返回結果大小成反比，即返回結果越小，qps越高；而實際上返回結構大小，search處理時間幾乎不會變化。 說明還是網絡的問題。

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

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

case 2: 2行22列，3臺merge

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。