¯\_(ツ)_/¯
: → 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的问题?
作者:
brucetu (sec)
2019-03-14 23:11:00因为你开头讲小型系统用REST好开发 效能难上去所以我才举例需要效能的大型系统也是会使用REST我举的例子是指他们的前端跟API Server串接不是他们更后端的内部服务在互串的情况
我认为大家不在讨论的点上，大型的网站仍是用RESTful API，你为了效能选用Protobuf确实也没错。但是说RESTful无法处理太多request是因为不想花钱的话，讲这些就没意义了
大型系统都走云端LB + autoscaling vm了 跟用啥没关吧
作者:
frouscy (流浪吧。)
2019-03-15 01:58:00你的大不是我的大 我感觉是这样XD 前端/API server的流量模式和更后端的资料处理系统的流量模式完全不一样呀
作者:
oopFoo (3d)
2019-03-15 07:47:00瞄了一下。丢几个ideas。还在用Jackson?要不要试试DSL-JSON?Jsoniter?有没有试试Netty, Undertow？听说Rapidoid是最快
作者:
y3k (激流を制するは静水)
2019-03-15 12:48:00如果有大量资料需求我自己是用Rest沟通带到对应的地方去处理
作者:
oopFoo (3d)
2019-03-15 13:55:00看design_doc文件。jetty(扣掉ssl)的部份花42%+的时间。没看程式但猜api是小量data in/out。cpu大概都在flushcache。然后ring transition也吃掉一堆时间。要improveperformance，先看Rapidoid有没有减少Thread switching。很多东西可以测试。garbage collection?cpu pinnning？...