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

要開始深度討論了嗎(買鹽酥雞跟準備筆記本

換成core 看看囉

(掏本本

看應用啊 大量數據 grpc 大勝啊

聽起來比較像沒有scaling的能力

這是scaling problem跟是不是用protobuf沒關吧

protobuf parse的速度比json快多了還有Jetty 的SSL太慢

該注意的是一條連線是否能同時處理多個 request 和 SSL加解密速度

請問換GRPC 效能快多少？

body 編碼速度應該不是瓶頸

問題是你搞錯方向了,這是另一個主題.service scaling這跟用不用rest沒有關係

沒試過GPRC但Hadoop RPC一秒可以幾十萬以上樓上 就是因為做rest的building block都不夠有效率阿如果有能跑rest+SSL能上一秒10萬個requests我會很有興趣 謝謝

https://www.youtube.com/watch?v=7TOWLerX0Ps給關鍵字沒興趣就沒交集好討論的了 就到此為止吧

alan的意思是api的形式跟你server內部怎麼處理無關吧rest也沒規定一定要json

restful api就是容易scale out。要scale out Hadoop KMSgoogle 一下 "hadoop kms high availability"

搞錯方向 , 照你這樣說FB 百度 淘寶 為什麼不用protobuf?整個系統的瓶頸不在parseJSON這段 還是以開發好做為主

好奇了解你跑 jetty 的硬體等級是什麼？ vm 的設定？