服務流程：

     輸入為一句話， 分詞、匹配百科詞條，讀redis過濾、從redis讀詞條summary資訊、返回

需求：

     業務方的峰值QPS為3000

按照之前相關百科的一套邏輯： 單機tornado服務程序數4個

模擬10個併發，壓測的QPS為332， 響應時間為30ms

$siege -c10 -r5000 -f urls.lst

Transactions:               10000 hits
Availability:              100.00 %
Elapsed time:               30.05 secs
Data transferred:            3.31 MB
Response time:                0.03 secs
Transaction rate:          332.78 trans/sec
Throughput:                0.11 MB/sec
Concurrency:                9.75
Successful transactions:       10000
Failed transactions:               0
Longest transaction:            0.65
Shortest transaction:            0.00
 

模擬20個併發

$siege -c20 -r5000 -f urls.lst

Transactions:               20000 hits
Availability:              100.00 %
Elapsed time:               58.39 secs
Data transferred:            6.72 MB
Response time:                0.06 secs
Transaction rate:          342.52 trans/sec
Throughput:                0.12 MB/sec
Concurrency:               19.77
Successful transactions:       20000
Failed transactions:               0
Longest transaction:            0.41
Shortest transaction:            0.00
 

壓測的QPS跟剛才幾乎差不多，但是響應時間已經上升到了60ms，可見，此時服務已經處理不過來了，大量的請求是處理等待狀態的， 然而20個併發在業務方來說應該還算少的

優化策略：

第一步：  

先增加服務程序數， 將單機的服務程序從4提高到10  

壓測：

$siege -c20 -r5000 -f urls.lst

QPS為700， 此時的response time是30ms

Transactions:               20000 hits
Availability:              100.00 %
Elapsed time:               28.26 secs
Data transferred:            6.72 MB
Response time:                0.03 secs
Transaction rate:          707.71 trans/sec
Throughput:                0.24 MB/sec
Concurrency:               19.47
Successful transactions:       20000
Failed transactions:               0
Longest transaction:            0.35
Shortest transaction:            0.00
 

第二步： 

減少詞表的數量

詞表是百科所有詞條的title和詞條id的對映關係， 總量為2300w，因為這個需求只要求PV大於75000的才返回結果，所以詞表也按照這個條件進行過濾， 過濾後，詞表只剩下了13w

再次壓測：

$siege -c20 -r5000 -f urls.lst

可以看到QPS提高到了1081， response time降低到了20ms

Transactions:               20000 hits
Availability:              100.00 %
Elapsed time:               18.50 secs
Data transferred:            5.84 MB
Response time:                0.02 secs
Transaction rate:         1081.08 trans/sec
Throughput:                0.32 MB/sec
Concurrency:               19.67
Successful transactions:       20000
Failed transactions:               0
Longest transaction:            0.09
Shortest transaction:            0.00

第三步：

對query做快取

因為query都是短文字，根據業務方的反饋，會存在大量的重複的query， 所以對query做快取肯定會起到效果

具體策略：

      對query分詞，分詞後拼接，並計算md5值作為快取的key， query對應的返回結果作為value快取到redis中

      因為有快取，所以這個壓測不太好測，而且我們暫時也沒有線上真實的資料，所以這裡無法給出壓測的結果，但是效果應該會很好

目前可以大概預估下， 加了快取後，單機的QPS應該能到1500， 那麼部署兩臺機器就可以滿足需求了