一次失敗的protobuf基準測試

之前看到pemelo資料的時候,作者曾提到對pemolo的一次優化,json的完全序列化成為伺服器訊息**的乙個瓶頸. 目前我的遊戲伺服器中使用了protocbuf作為協議, 它的表現很穩定.讓客戶端和我對於協議的交流很流暢,極大的提高了兩邊的開發效率. 看起來很完美.但我總隱隱的覺得不安. 我有時候會懷疑:

目前的protobuf的方式會不會有問題.會不會讓伺服器的對協議物件的序列化和反序列化成為伺服器的效能瓶頸.

由於我們遊戲的訊息型別比較多,大概有100種請求,為了方便對訊息的序列/反序列化的操作.一般會使用乙個大訊息包裹子訊息的方式來組織:

根據protobuf的官方文件描述了一種union type的組織形式來實現(

message onemessage 
required type type = 1;
optional foo foo = 2;
optional bar bar = 3;
optional baz baz = 4;
}

而在google group對此需求的討論中,有人提出了內嵌訊息位元組流的方式:

message onemessage 
required type type = 1;
required bytes innermessage = 2;
}

我最終採用了後乙個方法.因為我覺得前者會有三個缺點:

1. 大訊息體過於冗長,對於乙個子訊息型別可能有幾百種的專案來說,很難維護

2. 訊息中的可選訊息欄位過多.但都為null,每個被序列化後的訊息會占用很多無用的引用記憶體.而訊息物件的數量又恰恰是數量最為龐大.可能會有隱患.

3. 內嵌物件不是每次都需要序列化. 伺服器儲存了對話的狀態,每種狀態只能傳送型別的報文.如果客戶端改善的報文型別和伺服器狀態不對應.則可以直接丟棄報文.無必要序列化內部訊息.

就這樣,專案穩定的執行了一段時間,但偶然的一次debug, 發現protbuf的內部**對內部訊息的序列存在乙個效能隱患:

像protobuf中對位元組的定義: required bytes innermessage = 2;

probobuf在序列化的時候,都會轉化為不變的bytestring物件，但在生成bytestring物件時, 會對原始的訊息位元組陣列進行一次拷貝,再傳遞給序列化後的物件(參見codedinputstream.readbytes()).

雖然protbuf對位元組陣列的拷貝使用是system.arraycopy(native的 memcopy).但從功能上來說,這樣的拷貝對於我來說,完全沒有必要(google groups有人同樣對此產生了懷疑

相對於一次性序列化的union type方式,使用內嵌訊息位元組流的方式,會多做一次位元組陣列的拷貝.我很擔心這樣會產生效能問題.

於是為了比較這兩種方式.我做了乙個簡單的基本測試.

message pbtestnestpacket

message pbtestunionpacket

生成了兩種內容同樣的訊息,並分別生成訊息序列化後的位元組陣列, 然後對兩個不同的位元組陣列深度序列化.

各自執行不同的幾組測試,結果發現兩種方式的響應時間並無太大差異,在多數時候,巢狀位元組陣列的方式.響應時間更快.

報文大小測試輪數內嵌方式響應時間 union方式響應時間. report: size:20, testturn:5000 : nest: 167 union: 216 report: size:100, testturn:5000 nest 246 union 256 report: size:100, testturn:50000 nest 1163 union 1236 report: size:500, testturn:5000 nest 750 union 789 report: size:500, testturn:50000 nest 10122 union 10129 report: size:1000, testturn:5000 nest 1407 union 1421

report: size:5000, testturn:5000 nest 9471 union 9690

雖然產生了不科學的結果,但這次測試至少讓我自己放了心.目前的使用協議方式和另一種方式相比效能上沒有劣勢.維護性上提高了不少.

一次失敗的protobuf基準測試

一次失敗的聚會

一次失敗的面試

一次失敗的騎行

一次失敗的protobuf基準測試

一次失敗的聚會

一次失敗的面試

一次失敗的騎行

相關推薦