Re: [請益] 所以,到底什麼是RESTful API?

看板Soft_Job作者 (修身.齊家.治國.平天下)時間5年前 (2019/03/14 22:34), 5年前編輯推噓5(5推 0噓 20→)
留言25則, 7人參與, 5年前最新討論串7/8 (看更多)
¯\_(ツ)_/¯ : → alan3100: https://www.youtube.com/watch?v=7TOWLerX0Ps
03/13 12:27 : → alan3100: 給關鍵字沒興趣就沒交集好討論的了 就到此為止吧 03/13 12:29 : 推 thefattiger: alan的意思是api的形式跟你server內部怎麼處理無關吧 03/13 13:53 : → thefattiger: rest也沒規定一定要json 03/13 13:54 : 推 oopFoo: restful api就是容易scale out。要scale out Hadoop KMS 03/13 21:30 : → oopFoo: google 一下 "hadoop kms high availability" 03/13 21:31 這篇Hadoop doc是我寫的 拿我寫的doc來考我還滿好笑的 謝謝 理論上當然可以scale out. 問題是我幹嘛砸大錢用高級機器跑 結果只能處理每秒幾千個RPC 然後大部分時間都耗在無意義的overhead上 : → brucetu: 搞錯方向 , 照你這樣說FB 百度 淘寶 為什麼不用protobuf? 03/14 03:40 : → brucetu: 整個系統的瓶頸不在parseJSON這段 還是以開發好做為主 03/14 03:40 這些公司他們用的backend如Hadoop, HBase都是用protobuf阿 或者用thrift or GRPC 而且我要強調 scenario是有SSL的情況 這些web公司backend我想應該都沒有SSL : → dream1124: 好奇了解你跑 jetty 的硬體等級是什麼？ vm 的設定？ 03/14 09:46 上面的數字來自2x8 core Xeon 100GB ram 這樣 如果真的有興趣我正在做的事的話 追追這個JIRA 歡迎讀讀scope doc 看看profiler的圖 給我點建議 https://issues.apache.org/jira/browse/HADOOP-16119 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 73.93.155.24 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1552574049.A.8EE.html ※ 編輯: jojochuang (73.93.155.24), 03/14/2019 22:40:06 ※ 編輯: jojochuang (73.93.155.24), 03/14/2019 22:52:53
→
03/14 23:11, 5年前 , 1F
因為你開頭講小型系統用REST好開發 效能難上去
03/14 23:11, 1F
→
03/14 23:12, 5年前 , 2F
所以我才舉例需要效能的大型系統也是會使用REST
03/14 23:12, 2F
→
03/14 23:12, 5年前 , 3F
我舉的例子是指他們的前端跟API Server串接
03/14 23:12, 3F
→
03/14 23:12, 5年前 , 4F
不是他們更後端的內部服務在互串的情況
03/14 23:12, 4F
推
03/15 00:03, 5年前 , 5F
我認為大家不在討論的點上，大型的網站仍是用RESTful AP
03/15 00:03, 5F
→
03/15 00:03, 5年前 , 6F
I，你為了效能選用Protobuf確實也沒錯。但是說RESTful無
03/15 00:03, 6F
→
03/15 00:03, 5年前 , 7F
法處理太多request是因為不想花錢的話，講這些就沒意義
03/15 00:03, 7F
→
03/15 00:03, 5年前 , 8F
了
03/15 00:03, 8F
推
03/15 00:06, 5年前 , 9F
大型系統都走雲端LB + autoscaling vm了 跟用啥沒關吧
03/15 00:06, 9F
推
03/15 01:58, 5年前 , 10F
你的大不是我的大 我感覺是這樣XD 前端/API server的流量
03/15 01:58, 10F
→
03/15 01:59, 5年前 , 11F
模式和更後端的資料處理系統的流量模式完全不一樣呀
03/15 01:59, 11F
推
03/15 07:47, 5年前 , 12F
瞄了一下。丟幾個ideas。
03/15 07:47, 12F
→
03/15 07:48, 5年前 , 13F
還在用Jackson?要不要試試DSL-JSON?Jsoniter?
03/15 07:48, 13F
→
03/15 07:51, 5年前 , 14F
有沒有試試Netty, Undertow？聽說Rapidoid是最快
03/15 07:51, 14F
→
03/15 08:31, 5年前 , 15F
要從10k到100k，你們其實需要考慮的是redesign。是不是api
03/15 08:31, 15F
→
03/15 08:32, 5年前 , 16F
處理的事情太小太少？
03/15 08:32, 16F
→
03/15 10:29, 5年前 , 17F
聽起來像問題在REST → 用JSON → JSON慢 → NG
03/15 10:29, 17F
→
03/15 10:31, 5年前 , 18F
不用JSON→沒限定REST→所以是REST的問題?
03/15 10:31, 18F
→
03/15 12:48, 5年前 , 19F
如果有大量資料需求我自己是用Rest溝通帶到對應的地方去處理
03/15 12:48, 19F
推
03/15 13:55, 5年前 , 20F
看design_doc文件。jetty(扣掉ssl)的部份花42%+的時間。
03/15 13:55, 20F
→
03/15 13:58, 5年前 , 21F
沒看程式但猜api是小量data in/out。cpu大概都在flush
03/15 13:58, 21F
→
03/15 13:59, 5年前 , 22F
cache。然後ring transition也吃掉一堆時間。要improve
03/15 13:59, 22F
→
03/15 14:01, 5年前 , 23F
performance，先看Rapidoid有沒有減少Thread switching。
03/15 14:01, 23F
→
03/15 14:04, 5年前 , 24F
很多東西可以測試。garbage collection?cpu pinnning？...
03/15 14:04, 24F
→
03/15 14:13, 5年前 , 25F
吃最多的是fill()。這大概是data copying between thread
03/15 14:13, 25F
‣ 更多 jojochuang 的文章
文章代碼(AID): #1SYcPXZk (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 7 之 8 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共8篇)
‣ 更多 jojochuang 的文章
文章代碼(AID): #1SYcPXZk (Soft_Job)