作者jojochuang (修身.齐家.治国.平天下)
看板Soft_Job
标题Re: [请益] 所以,到底什麽是RESTful API?
时间Thu Mar 14 22:34:07 2019
¯\_(ツ)_/¯
: → 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://webptt.com/cn.aspx?n=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
1F：→ brucetu: 因为你开头讲小型系统用REST好开发 效能难上去 03/14 23:11
2F：→ brucetu: 所以我才举例需要效能的大型系统也是会使用REST 03/14 23:12
3F：→ brucetu: 我举的例子是指他们的前端跟API Server串接 03/14 23:12
4F：→ brucetu: 不是他们更後端的内部服务在互串的情况 03/14 23:12
5F：推 lemon651: 我认为大家不在讨论的点上，大型的网站仍是用RESTful AP 03/15 00:03
6F：→ lemon651: I，你为了效能选用Protobuf确实也没错。但是说RESTful无 03/15 00:03
7F：→ lemon651: 法处理太多request是因为不想花钱的话，讲这些就没意义 03/15 00:03
8F：→ lemon651: 了 03/15 00:03
9F：推 jinmin88: 大型系统都走云端LB + autoscaling vm了 跟用啥没关吧 03/15 00:06
10F：推 frouscy: 你的大不是我的大 我感觉是这样XD 前端/API server的流量 03/15 01:58
11F：→ frouscy: 模式和更後端的资料处理系统的流量模式完全不一样呀 03/15 01:59
12F：推 oopFoo: 瞄了一下。丢几个ideas。 03/15 07:47
13F：→ oopFoo: 还在用Jackson?要不要试试DSL-JSON?Jsoniter? 03/15 07:48
14F：→ oopFoo: 有没有试试Netty, Undertow？听说Rapidoid是最快 03/15 07:51
15F：→ oopFoo: 要从10k到100k，你们其实需要考虑的是redesign。是不是api 03/15 08:31
16F：→ oopFoo: 处理的事情太小太少？ 03/15 08:32
17F：→ dreamnook: 听起来像问题在REST → 用JSON → JSON慢 → NG 03/15 10:29
18F：→ dreamnook: 不用JSON→没限定REST→所以是REST的问题? 03/15 10:31
19F：→ y3k: 如果有大量资料需求我自己是用Rest沟通带到对应的地方去处理 03/15 12:48
20F：推 oopFoo: 看design_doc文件。jetty(扣掉ssl)的部份花42%+的时间。 03/15 13:55
21F：→ oopFoo: 没看程式但猜api是小量data in/out。cpu大概都在flush 03/15 13:58
22F：→ oopFoo: cache。然後ring transition也吃掉一堆时间。要improve 03/15 13:59
23F：→ oopFoo: performance，先看Rapidoid有没有减少Thread switching。 03/15 14:01
24F：→ oopFoo: 很多东西可以测试。garbage collection?cpu pinnning？... 03/15 14:04
25F：→ oopFoo: 吃最多的是fill()。这大概是data copying between thread 03/15 14:13