搜狗伺服器引擎Sogou C++ Workflow開源啦!

夢共裡醉發表於2020-09-23
搜狗公司開源了其 C++ 伺服器引擎 Sogou C++ Workflow,這一引擎實現了高效能、輕量級落地,還引入任務流概念,實現了計算任務與通訊任務的統一和協同排程。

搜狗伺服器引擎Sogou C++  Workflow開源啦!搜狗伺服器引擎Sogou C++  Workflow開源啦!

據介紹,目前該引擎支撐著搜狗幾乎所有後端 C++ 線上服務,包括所有搜尋服務、雲輸入法與線上廣告等,每日處理數百億請求。

Sogou C++ Workflow 在設計之初,就秉持著高效能與輕量級兩個核心理念。長久以來,業界中最佳化伺服器效能都主要專注於如何跑滿 cpu、如何單獨地讓網路請求極速響應等方面。而此次上線的搜狗 Workflow 則更專注於如何讓各種網路資源被具體的排程器管理,使其儘可能地全部排程起來。

搜狗伺服器引擎Sogou C++  Workflow開源啦!搜狗伺服器引擎Sogou C++  Workflow開源啦!

另一方面,對多通訊計算資源融為一體的解決方案,進一步提升了 Workflow 引擎的效能。過去開發者在面臨選擇高吞吐網路框架時,需要自己面對不同計算資源比例而劃分不同大小的執行緒池。然而每種計算具體資源需求比例是動態變化的,重要性也不一樣,後端響應時長也是動態變動。Sogou C++ Workflow 使得 C++ 伺服器引擎也能像 Go 語言一樣,實現網路資源非同步排程,並且進一步打通計算與磁碟等資源。

此專案最大的亮點可能是創新性引入了任務流的概念,Sogou C++ Workflow 將資源高度封裝,使用者再也接觸不到連線池、執行緒池,包括想要做 aio 時的檔案 fd 與各種非同步通知機制。這就意味著,在開發階段開發人員僅僅需要了解業務關係而不用關心內部細節,幫助開發者們實現自己複雜的業務邏輯。

開發人員可以利用 Sogou C++ Workflow 封裝好的各種任務來動態或靜態組建自己的業務邏輯,如下圖所示,不同型別的任務都可以被序列、並行到一起:

根據資料,除了各種創新設計以外,Sogou C++ Workflow 還擁有友好的使用者體驗。Sogou C++ Workflow 原生實現了對http、redis、mysql 和 kafka 等協議的支援,可以直接作為這些協議的客戶端使用。並且在其基礎上開發了一套更加易用的 Sogou RPC,實現了與 brpc 和 thrift 互通,並且可以透過 http+json 或 IDL 實現跨語言。

開發團隊透露,Sogou RPC 專案也會在不久的將來開源。

Http Server 效能實測:Sogou C++ Workflow VS nginx、brpc

搜狗團隊也提供了 Sogou C++ Workflow 和 nginx、brpc 兩個主流系統的 http server 效能對比。

測試環境:

選取了最基本的測試場景:wrk 或者 wrk2 跨機做 client,單 server,長連線,CPU:40 核 E5-2630 v4 @ 2.20GHz,記憶體:192GB,網路卡:25000Mb/s。nginx 配置了 auto 的程式數(與核數一致),brpc 配置了 40 個 nthreads,workflow 配置了 16 個 poller 執行緒和 20 個 handler 執行緒。

測試一:不同併發數對 QPS 的影響(越高越好)

搜狗伺服器引擎Sogou C++  Workflow開源啦!搜狗伺服器引擎Sogou C++  Workflow開源啦!

結論:隨著壓測併發數的增加,server 的 QPS 會隨著增高。可以看到 Workflow 無論是低併發數還是高併發數的情況下,QPS 依然比 nginx 和 brpc 要高,尤其是併發數超過 128 的時候優勢更加明顯,Workfow 對於小包基本能保證 50w 的 QPS,說明內部對網路資源的高併發排程做了很多最佳化。

測試二:不同資料大小對 QPS 的影響(越高越好)

搜狗伺服器引擎Sogou C++  Workflow開源啦!搜狗伺服器引擎Sogou C++  Workflow開源啦!

結論:此處的返回包大小是 http 請求的 body 大小,隨著返回包增大,QPS 會有所下降,我們希望 QPS 依然儘可能保持平穩不要下降得太快。Workflow 在同併發下的效能依然比其他兩個系統要好,說明網路收發和其他呼叫之間的排程協調得更好。

測試三:固定 QPS 下的延遲分佈 CDF 圖(越左越好,越直越好)

搜狗伺服器引擎Sogou C++  Workflow開源啦!搜狗伺服器引擎Sogou C++  Workflow開源啦!

結論:

本測試由 wrk2 進行固定 QPS 的壓測,其中還有 1% 的長尾請求 Outiler,長尾請求不計入結果,因為我們關注的是模擬真實情況下普通請求能否被及時處理。由於 nginx 在其他測試中效能略差一截,因此沒有對其進行 CDF 對比。可以看到在不同比例的分佈中,Workflow 的延遲更低、且最慢的那些(0.99 到 1.00 之間)延遲增長也相對緩慢,說明 Workflow 對長尾處理更及時。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31524109/viewspace-2723358/,如需轉載,請註明出處,否則將追究法律責任。

相關文章