作者jojochuang (修身.齊家.治國.平天下)
看板Soft_Job
標題Re: [請益] 所以,到底什麼是RESTful API?
時間Tue Mar 12 23:18:08 2019
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
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 107.3.154.248
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1552403891.A.709.html
1F：→ dreamnook: 要開始深度討論了嗎(買鹽酥雞跟準備筆記本 03/12 23:23
2F：推 neo5277: 換成core 看看囉 03/12 23:26
3F：推 kokolotl: (掏本本 03/12 23:39
4F：推 anr2: 看應用啊 大量數據 grpc 大勝啊 03/12 23:50
5F：→ alan3100: 聽起來比較像沒有scaling的能力 03/13 00:35
6F：推 lemon651: 這是scaling problem跟是不是用protobuf沒關吧 03/13 00:44
7F：→ jojochuang: protobuf parse的速度比json快多了 03/13 09:23
8F：→ jojochuang: 還有Jetty 的SSL太慢 03/13 09:23
9F：→ mkmkdada: 該注意的是一條連線是否能同時處理多個 request 和 SSL 03/13 09:37
10F：→ mkmkdada: 加解密速度 03/13 09:37
11F：→ pttuser2266: 請問換GRPC 效能快多少？ 03/13 09:38
12F：→ mkmkdada: body 編碼速度應該不是瓶頸 03/13 09:39
13F：→ alan3100: 問題是你搞錯方向了,這是另一個主題.service scaling 03/13 09:41
14F：→ alan3100: 這跟用不用rest沒有關係 03/13 09:42
15F：→ jojochuang: 沒試過GPRC但Hadoop RPC一秒可以幾十萬以上 03/13 09:51
16F：→ jojochuang: 樓上 就是因為做rest的building block都不夠有效率阿 03/13 09:56
17F：→ jojochuang: 如果有能跑rest+SSL能上一秒10萬個requests我會很有興 03/13 09:57
18F：→ jojochuang: 趣 謝謝 03/13 09:57
20F：→ alan3100: 給關鍵字沒興趣就沒交集好討論的了 就到此為止吧 03/13 12:29
21F：推 thefattiger: alan的意思是api的形式跟你server內部怎麼處理無關吧 03/13 13:53
22F：→ thefattiger: rest也沒規定一定要json 03/13 13:54
23F：推 oopFoo: restful api就是容易scale out。要scale out Hadoop KMS 03/13 21:30
24F：→ oopFoo: google 一下 "hadoop kms high availability" 03/13 21:31
25F：→ brucetu: 搞錯方向 , 照你這樣說FB 百度 淘寶 為什麼不用protobuf? 03/14 03:40
26F：→ brucetu: 整個系統的瓶頸不在parseJSON這段 還是以開發好做為主 03/14 03:40
27F：→ dream1124: 好奇了解你跑 jetty 的硬體等級是什麼？ vm 的設定？ 03/14 09:46