→ brucetu: 因為你開頭講小型系統用REST好開發 效能難上去 03/14 23:11
→ brucetu: 所以我才舉例需要效能的大型系統也是會使用REST 03/14 23:12
→ brucetu: 我舉的例子是指他們的前端跟API Server串接 03/14 23:12
→ brucetu: 不是他們更後端的內部服務在互串的情況 03/14 23:12
推 lemon651: 我認為大家不在討論的點上，大型的網站仍是用RESTful AP 03/15 00:03
→ lemon651: I，你為了效能選用Protobuf確實也沒錯。但是說RESTful無 03/15 00:03
→ lemon651: 法處理太多request是因為不想花錢的話，講這些就沒意義 03/15 00:03
→ lemon651: 了 03/15 00:03
推 jinmin88: 大型系統都走雲端LB + autoscaling vm了 跟用啥沒關吧 03/15 00:06
推 frouscy: 你的大不是我的大 我感覺是這樣XD 前端/API server的流量 03/15 01:58
→ frouscy: 模式和更後端的資料處理系統的流量模式完全不一樣呀 03/15 01:59
推 oopFoo: 瞄了一下。丟幾個ideas。 03/15 07:47
→ oopFoo: 還在用Jackson?要不要試試DSL-JSON?Jsoniter? 03/15 07:48
→ oopFoo: 有沒有試試Netty, Undertow？聽說Rapidoid是最快 03/15 07:51
→ oopFoo: 要從10k到100k，你們其實需要考慮的是redesign。是不是api 03/15 08:31
→ oopFoo: 處理的事情太小太少？ 03/15 08:32
→ dreamnook: 聽起來像問題在REST → 用JSON → JSON慢 → NG 03/15 10:29
→ dreamnook: 不用JSON→沒限定REST→所以是REST的問題? 03/15 10:31
→ y3k: 如果有大量資料需求我自己是用Rest溝通帶到對應的地方去處理 03/15 12:48
推 oopFoo: 看design_doc文件。jetty(扣掉ssl)的部份花42%+的時間。 03/15 13:55
→ oopFoo: 沒看程式但猜api是小量data in/out。cpu大概都在flush 03/15 13:58
→ oopFoo: cache。然後ring transition也吃掉一堆時間。要improve 03/15 13:59
→ oopFoo: performance，先看Rapidoid有沒有減少Thread switching。 03/15 14:01
→ oopFoo: 很多東西可以測試。garbage collection?cpu pinnning？... 03/15 14:04
→ oopFoo: 吃最多的是fill()。這大概是data copying between thread 03/15 14:13