草草在线免费观看视频,亚洲无码视频在线免费观看 ,欧美日韩性爱,国产三级午夜理伦三级,中文字幕欧美在线,人人插人人操,特级西西人体444WWwtini,国产精品久久久久久精

有朋友問，每年年初的時候我會發(fā)布一個RPC的框架的大比拼，今年為啥沒有了？

有幾個原因，一是我去年下半年換了一份工作，熟悉新的業(yè)務耗費了很大精力，導致博客文章相對少了，開源的貢獻也少了，二是RPCX我自己覺得性能已經(jīng)很不錯了沒有想著進一步的優(yōu)化，所以也沒有做相應的benchmark比較。

前幾個星期頭條的同學推出他們的RPCX框架KiteX[1]，據(jù)說性能要比RPCX和gRPC好很多，加上今年GopherChina2021大會上他們也分享了他們的netpoll的優(yōu)化。

本來，我對自定義epoll一類的框架如evio、gnet是不感冒的，因為Go本身的net庫也是基于epoll實現(xiàn)的，只不過這類框架在處理epoll事件之后的處理和標準庫是不一樣的。在GopherChina大會上我也和小伙伴說，我擔心的這類框架的“長尾效應”，也就是從客戶端視角看，大大并發(fā)的情況下latency的長尾效應可能是一個很大的痛點。這個話題我一直想專門寫一篇文章探討一下，希望這個秋季能出一篇深度分析標準庫和自定義epoll的文章。

當然，既然頭條的同學測試KiteX性能不錯，那么我也就把KiteX加入到我的RPC benchmark項目[2]中了，并且在這個周末也對幾種Go RPC框架做了benchmark對比，我想自己測試看看這些框架的性能表現(xiàn)。

當然，每次發(fā)表benchmark文章，我都會先聲明，沒有一個benchmark可以全面的反應這些框架的完整的性能的，更不用說完整的特性了。每個人在使用RPC框架時，面對的場景可能都不同，有些是CPU敏感的服務、有的是IO敏感的服務、有的是內(nèi)存敏感的服務、有的是讀數(shù)據(jù)庫的服務、有的是提供緩存的服務、有些是寫文件的服務，消息的長度有大有小、消息的編碼格式也不盡相同，有的是同步調(diào)用，有的是異步調(diào)用，有些是同機房的調(diào)用，有些是跨機房的調(diào)用，有些用TCP，有些用UDP，......各種各樣五花八門，所以沒有一種benchmark可以涵蓋所有的場景。這次我做的benchmark，也只是覆蓋了其中的一種場景。但是幸運的是，這個項目提供了一個框架，可以根據(jù)你的場景自己定制，如果你感興趣，你可以在這個項目的基礎(chǔ)上做一些修改，以便和你的使用場景做匹配。

另外，性能只是比較RPC框架的一個方面，千萬不要因為測試結(jié)果A框架比B框架好就拿去吹噓，那是幼稚的表現(xiàn)。另外也不可能Go生態(tài)圈只有一個框架存在，目前Go生態(tài)圈至少有十幾個框架存在，各有特色。我個人對于Go生態(tài)圈的微服務框架持開放態(tài)度，而且也會了解和學習其它框架的優(yōu)點，讓RPCX框架變得更好，我相信其他開發(fā)者也是這么想的。

想比以前的測試，我把Dubbo、Motan、Tarsgo等RPC框架去掉了。我個人不認為這些框架真的適合Go生態(tài)群的開發(fā)。Go的設計哲學就是簡單，這幾種框架都需要復雜的配置。當然我知道這些框架原先是Java、C++語言的，只不過為了跨語言才port到Go生態(tài)圈，導致這些框架的使用非常的復雜，因為為了保持和主語言的框架的兼容。如果單純的Go生態(tài)圈的使用的話，我還是建議挑選簡單可依賴的純Go生態(tài)圈的框架。

為了盡量保持一致的測試環(huán)境，所有的框架統(tǒng)一遵循下面的約定：

分別測試并發(fā)數(shù)為100、200、500、1000、2000、5000的場景，測試單個服務在面對不同并發(fā)量的情況下的性能。
從客戶端統(tǒng)計吞吐率和延遲（latency）
采用共享的client。創(chuàng)建一定數(shù)量的client作為client池。
所有的框架都是在“公平”的情況下測試。測試數(shù)據(jù)都是一致的，采用Protobuf進行測試。雖然有比Protobuf性能更好的序列化框架，但是因為不具有通用性所以不考慮。
測試會進行預熱。
避免coordinated omission[3]：測試統(tǒng)計的是等待時間+服務時間，而不是服務端服務時間
統(tǒng)計既包含平均值，也包含P99.9值。

測試環(huán)境

Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz，2顆
總物理核8個，開超線程邏輯核數(shù)為32個
內(nèi)存128G
Go 1.16.6
各框架版本：

ARPC：1.1.5
go std rpc：1.16.6
gRPC：1.39.0
KiteX：0.0.3
RPCX：1.6.5

測試是在單機上進行的。壞處就是測試是沒有像實際情況一樣經(jīng)過實際網(wǎng)絡，而是本機網(wǎng)絡支持處理，好處就是我們可以刨去長距離或者不好的網(wǎng)絡的影響，只關(guān)注于RPC框架的處理。

測試步驟

生成每個框架的服務端和客戶端：

-rwxr-xr-x 1 smallnest USER  9756450 Aug  1 17:50 arpc_server
-rwxr-xr-x 1 smallnest USER 12800584 Aug  1 17:51 gostd_server
-rwxr-xr-x 1 smallnest USER 12520016 Aug  1 17:52 grpc_server
-rwxr-xr-x 1 smallnest USER 11240760 Aug  1 17:53 kitex_server
-rwxr-xr-x 1 smallnest USER 11810350 Aug  1 17:54 rpcx_server

-rwxr-xr-x 1 smallnest USER  5021980 Aug  1 17:56 arpc_client
-rwxr-xr-x 1 smallnest USER 11109233 Aug  1 17:57 gostd_client
-rwxr-xr-x 1 smallnest USER 12581237 Aug  1 17:58 grpc_client
-rwxr-xr-x 1 smallnest USER 11559544 Aug  1 17:59 kitex_client
-rwxr-xr-x 1 smallnest USER 16065065 Aug  1 18:00 rpcx_client

啟動服務端：

./xxx_server -d 127.0.0.1:8972

客戶端測試（并發(fā)數(shù)100）：

./xxx_client -c 1000 -n 10000000 -s 127.0.0.1:8973

每個場景會發(fā)送一千萬個請求，內(nèi)容一個不大不小的Protobuf編碼的數(shù)據(jù)，服務端收到后會設置某個字段為OK，并返回。沒有復雜的計算。

相對于簡單的echo字符串的服務，消息體適中，編碼格式通用，業(yè)務處理簡單，耗時很短吞吐率有保障。

測試結(jié)果

當前對5種RPC框架做了測試，有些是普通的RPC服務，比如ARPC、Go標準庫中的RPC、有些是支持微服務治理的框架如KiteX、RPCX，有些是有一些微服務治理的功能如gRPC。測試的時候，并沒有測試他們的微服務治理的功能，而是只是測試了他們簡單的RPC調(diào)用。

實際測試是，發(fā)現(xiàn)KiteX在并發(fā)數(shù)為2000的時候，客戶端調(diào)用會有少量出錯，并發(fā)數(shù)為5000時，會有10+%的調(diào)用出錯。

吞吐率（越高越好）

也就是每秒完成的調(diào)用數(shù)。

延遲（平均耗時，越小越好）

單位毫秒。

延遲（P99.9耗時，越小越好）

單位毫秒。

原始測試數(shù)據(jù)

簡單總結(jié)

ARPC表現(xiàn)亮眼，吞吐率和耗時表現(xiàn)都不錯。它是一個類似Go Web編程風格的RPC框架，采用router和handler的方式實現(xiàn)服務，值的學習。

KiteX在并發(fā)量小的時候吞吐率要比RPCX要好，隨著并發(fā)量增多，吞吐率基本差不多，吞吐率在大一些，它的長尾效應很明顯P99.9延遲很高，這符合我對自定義epoll框架的推測。如果有小伙伴有不同的想法，歡迎發(fā)送評論。

Go標準庫RPC框架中規(guī)中矩。

RPCX框架表現(xiàn)優(yōu)異，在各種并發(fā)量的情況下都領(lǐng)先，并且沒有明顯的長尾效應。

gRPC本來也是很不錯的框架，但是性能和這幾位比起來，還稍差一些。

通過這次測試，我對RPCX當前的性能有了一個大致的了解，并且通過對其它RPC框架測試，又進一步優(yōu)化了RPCX的性能。

可能這個測試對于基于netpoll的KiteX不“公平”，我的理解是自定義netpoll適合那種有巨量socket連接，并發(fā)量適中的場景。

相關(guān)鏈接：

https://github.com/cloudwego/kitex
https://github.com/rpcxio/rpcx-benchmark
http://highscalability.com/blog/2015/10/5/your-load-generator-is-probably-lying-to-you-take-the-red-pi.html

原文鏈接：https://colobu.com/2021/08/01/benchmark-of-rpc-frameworks/

推薦閱讀

Go標準庫http與fasthttp服務端性能比較

福利

我為大家整理了一份從入門到進階的Go學習資料禮包，包含學習建議：入門看什么，進階看什么。關(guān)注公眾號「polarisxu」，回復 ebook 獲取；還可以回復「進群」，和數(shù)萬 Gopher 交流學習。

2021年Go生態(tài)圈RPC框架哪個性能最好？