¯\_(ツ)_/¯
: → 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

聽起來像問題在REST → 用JSON → JSON慢 → NG不用JSON→沒限定REST→所以是REST的問題?

因為你開頭講小型系統用REST好開發 效能難上去所以我才舉例需要效能的大型系統也是會使用REST我舉的例子是指他們的前端跟API Server串接不是他們更後端的內部服務在互串的情況

我認為大家不在討論的點上，大型的網站仍是用RESTful API，你為了效能選用Protobuf確實也沒錯。但是說RESTful無法處理太多request是因為不想花錢的話，講這些就沒意義了

大型系統都走雲端LB + autoscaling vm了 跟用啥沒關吧

你的大不是我的大 我感覺是這樣XD 前端/API server的流量模式和更後端的資料處理系統的流量模式完全不一樣呀

瞄了一下。丟幾個ideas。還在用Jackson?要不要試試DSL-JSON?Jsoniter?有沒有試試Netty, Undertow？聽說Rapidoid是最快

如果有大量資料需求我自己是用Rest溝通帶到對應的地方去處理

看design_doc文件。jetty(扣掉ssl)的部份花42%+的時間。沒看程式但猜api是小量data in/out。cpu大概都在flushcache。然後ring transition也吃掉一堆時間。要improveperformance，先看Rapidoid有沒有減少Thread switching。很多東西可以測試。garbage collection?cpu pinnning？...