RESTful API在开发小型系统时满容易开发 但是效能很难上去
我自己实测如果用Jetty当http server的话
在有SSL的情况一秒钟只能接受3千个connection
如果有connection reuse的情况下最多只能处理每秒一万个request
部分的原因是parse JSON的效能不好 部分的原因是Jetty本身implementation不好
高效能的系统可能还是得改用GRPC或是其他transport layer
===
我的例子是开发Hadoop Key Management Server做Hadoop资料加密的系统
几年前实作时为了简单用了RESTful API。现在客户真的认真用这功能后
性能根本撑不上去 所以现在得要重写
打算改用Protobuf + Hadoop RPC换掉REST + Jetty
作者:
neo5277 (I am an agent of chaos)
2019-03-12 23:26:00换成core 看看囉
作者:
kokolotl (nooooooooooo)
2019-03-12 23:39:00(掏本本
作者:
anr2 (???)
2019-03-12 23:50:00看应用啊 大量数据 grpc 大胜啊
这是scaling problem跟是不是用protobuf没关吧
protobuf parse的速度比json快多了还有Jetty 的SSL太慢
作者: mkmkdada (mkmkdada) 2019-03-13 09:37:00
该注意的是一条连线是否能同时处理多个 request 和 SSL加解密速度
作者: pttuser2266 2019-03-13 09:38:00
请问换GRPC 效能快多少？
作者: mkmkdada (mkmkdada) 2019-03-13 09:39:00
body 编码速度应该不是瓶颈
问题是你搞错方向了,这是另一个主题.service scaling这跟用不用rest没有关系
没试过GPRC但Hadoop RPC一秒可以几十万以上楼上 就是因为做rest的building block都不够有效率阿如果有能跑rest+SSL能上一秒10万个requests我会很有兴趣 谢谢
alan的意思是api的形式跟你server内部怎么处理无关吧rest也没规定一定要json
作者:
oopFoo (3d)
2019-03-13 21:30:00restful api就是容易scale out。要scale out Hadoop KMSgoogle 一下 "hadoop kms high availability"
作者:
brucetu (sec)
2019-03-14 03:40:00搞错方向 , 照你这样说FB 百度 淘宝 为什么不用protobuf?整个系统的瓶颈不在parseJSON这段 还是以开发好做为主
好奇了解你跑 jetty 的硬件等级是什么？ vm 的设定？