RESTful API在開發小型系統時滿容易開發 但是效能很難上去
我自己實測如果用Jetty當http server的話
在有SSL的情況一秒鐘只能接受3千個connection
如果有connection reuse的情況下最多只能處理每秒一萬個request
部分的原因是parse JSON的效能不好 部分的原因是Jetty本身implementation不好
高效能的系統可能還是得改用GRPC或是其他transport layer
===
我的例子是開發Hadoop Key Management Server做Hadoop資料加密的系統
幾年前實作時為了簡單用了RESTful API。現在客戶真的認真用這功能後
性能根本撐不上去 所以現在得要重寫
打算改用Protobuf + Hadoop RPC換掉REST + Jetty
作者:
neo5277 (I am an agent of chaos)
2019-03-12 23:26:00換成core 看看囉
作者:
kokolotl (nooooooooooo)
2019-03-12 23:39:00(掏本本
作者:
anr2 (???)
2019-03-12 23:50:00看應用啊 大量數據 grpc 大勝啊
這是scaling problem跟是不是用protobuf沒關吧
protobuf parse的速度比json快多了還有Jetty 的SSL太慢
作者: mkmkdada (mkmkdada) 2019-03-13 09:37:00
該注意的是一條連線是否能同時處理多個 request 和 SSL加解密速度
作者: pttuser2266 2019-03-13 09:38:00
請問換GRPC 效能快多少？
作者: mkmkdada (mkmkdada) 2019-03-13 09:39:00
body 編碼速度應該不是瓶頸
問題是你搞錯方向了,這是另一個主題.service scaling這跟用不用rest沒有關係
沒試過GPRC但Hadoop RPC一秒可以幾十萬以上樓上 就是因為做rest的building block都不夠有效率阿如果有能跑rest+SSL能上一秒10萬個requests我會很有興趣 謝謝
alan的意思是api的形式跟你server內部怎麼處理無關吧rest也沒規定一定要json
作者:
oopFoo (3d)
2019-03-13 21:30:00restful api就是容易scale out。要scale out Hadoop KMSgoogle 一下 "hadoop kms high availability"
作者:
brucetu (sec)
2019-03-14 03:40:00搞錯方向 , 照你這樣說FB 百度 淘寶 為什麼不用protobuf?整個系統的瓶頸不在parseJSON這段 還是以開發好做為主
好奇了解你跑 jetty 的硬體等級是什麼？ vm 的設定？