gRPC比rest API好在哪里？ - 未名空间MITBBS历史存档

b*t2017-07-25 07:07

1 楼

1. 学习他们的入场时机，我们版上的同学频频入市，频频出事，胜率上已经吃很大亏
了；
2. 学习他们入场的方式，比如巴菲特买的GS优先股，每年10%的yield还有转换成一般
股票的机会，这样做亏的几率有多大呢？你们可以算一算，然后和我们版上所有提到
过的粮票比比。
3. 学习他们入场资金的比例，虽然大户入场动辄几十亿，但是和他们可以动用的资金
相比还是占很小的比例的，大户们动手了，但是留有足够的后手，未雨绸缪，大家一定
要留有备用资金，不要动辄孤军深入，没有后援。
4. 学习大户选择投资的对象，李嘉诚为什么没有投资备受打压的中概太阳能呢，也许
版上的同学永远不会明白，如果有几十万，那个什么LDK, STP, CSIQ，YGE起码要狂抄
一气吧，想想为什么。
我们要学习大户的野心，和因为这种野心带来的冷静。职业杀手都是不经常动手的，但
是动手就要人性命，我们都有一颗想要赚钱的心，但是这种欲望还没有狂野到控制我们
急躁的程度，凡是有大野心的人，也是非常有耐心的人。我希望现在暂时受困的同学
都抱有一种苏武牧羊，卧薪尝胆的心态，而不是像退出的那些人一样没有精神，没有斗
志。希望版上的青铜

x*52017-07-25 07:07

2 楼

1，邓紫棋：喜欢没商量，虽然没汪峰摇滚，但不沙哑的存在合我胃口，何况小姑娘这
么萌这么可爱。
2，罗琦：唱功没的说，希望听她多唱几首。听她唱歌的机会太少了。
3，韦唯：虽然老调，但这么好听的中音难得听到
4，曹格：喜欢不同于赵传的味道，很好听，被淘汰实在可惜
5，周笔畅：烦人的形象，歌还别致
6，张宇：不是我的菜，听着有点憋闷
7，韩磊：不喜欢就是不喜欢，真希望被淘汰的是他，没惊喜太老套，都是一个劲儿

s*k2017-07-25 07:07

3 楼

看到很多都在从REST API转向gRPC，是因为JSON的格式太繁琐？protobuf好？还是说内
部应用不需要expose interface，gRPC更有效率？

d*l2017-07-25 07:07

4 楼

see 2208

P*r2017-07-25 07:07

5 楼

1, 5, 2, 4, 3, 6, 7
跟你略有同感
感觉评委中上年级的人太多

【在 x****5 的大作中提到】

: 1，邓紫棋：喜欢没商量，虽然没汪峰摇滚，但不沙哑的存在合我胃口，何况小姑娘这
: 么萌这么可爱。
: 2，罗琦：唱功没的说，希望听她多唱几首。听她唱歌的机会太少了。
: 3，韦唯：虽然老调，但这么好听的中音难得听到
: 4，曹格：喜欢不同于赵传的味道，很好听，被淘汰实在可惜
: 5，周笔畅：烦人的形象，歌还别致
: 6，张宇：不是我的菜，听着有点憋闷
: 7，韩磊：不喜欢就是不喜欢，真希望被淘汰的是他，没惊喜太老套，都是一个劲儿

w*g2017-07-25 07:07

6 楼

我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
主要是好在HTTP是标准，服务器/客户的库和工具都很多。
并且协议非常flexible，可以很容易地往里面加调试用的内容。
那些特定协议我觉得主要是性能好。

【在 s********k 的大作中提到】

: 看到很多都在从REST API转向gRPC，是因为JSON的格式太繁琐？protobuf好？还是说内
: 部应用不需要expose interface，gRPC更有效率？

b*t2017-07-25 07:07

7 楼

1. 学习他们的入场时机，我们版上的同学频频入市，频频出事，胜率上已经吃很大亏
了；
2. 学习他们入场的方式，比如巴菲特买的GS优先股，每年10%的yield还有转换成一般
股票的机会，这样做亏的几率有多大呢？你们可以算一算，然后和我们版上所有提到
过的粮票比比。
3. 学习他们入场资金的比例，虽然大户入场动辄几十亿，但是和他们可以动用的资金
相比还是占很小的比例的，大户们动手了，但是留有足够的后手，未雨绸缪，大家一定
要留有备用资金，不要动辄孤军深入，没有后援。
4. 学习大户选择投资的对象，李嘉诚为什么没有投资备受打压的中概太阳能呢，也许
版上的同学永远不会明白，如果有几十万，那个什么LDK, STP, CSIQ，YGE起码要狂抄
一气吧，想想为什么。
我们要学习大户的野心，和因为这种野心带来的冷静。职业杀手都是不经常动手的，但
是动手就要人性命，我们都有一颗想要赚钱的心，但是这种欲望还没有狂野到控制我们
急躁的程度，凡是有大野心的人，也是非常有耐心的人。我希望现在暂时受困的同学
都抱有一种苏武牧羊，卧薪尝胆的心态，而不是像退出的那些人一样没有精神，没有斗
志。希望版上的青铜斗士能赶快成长，努力学习，爆发你的小宇宙！不经历风雨，怎能
见彩虹，危机后你们必将成为一代黄金斗士！

M*u2017-07-25 07:07

8 楼

前两个确实不错。

【在 x****5 的大作中提到】

: 1，邓紫棋：喜欢没商量，虽然没汪峰摇滚，但不沙哑的存在合我胃口，何况小姑娘这
: 么萌这么可爱。
: 2，罗琦：唱功没的说，希望听她多唱几首。听她唱歌的机会太少了。
: 3，韦唯：虽然老调，但这么好听的中音难得听到
: 4，曹格：喜欢不同于赵传的味道，很好听，被淘汰实在可惜
: 5，周笔畅：烦人的形象，歌还别致
: 6，张宇：不是我的菜，听着有点憋闷
: 7，韩磊：不喜欢就是不喜欢，真希望被淘汰的是他，没惊喜太老套，都是一个劲儿

L*82017-07-25 07:07

9 楼

有啥推荐的开源库？

【在 w***g 的大作中提到】

: 我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
: 主要是好在HTTP是标准，服务器/客户的库和工具都很多。
: 并且协议非常flexible，可以很容易地往里面加调试用的内容。
: 那些特定协议我觉得主要是性能好。

d*l2017-07-25 07:07

10 楼

see 2208

C*s2017-07-25 07:07

11 楼

这个邓紫棋还是算了吧，台湾宰，唱的都快憋死了

【在 x****5 的大作中提到】

: 1，邓紫棋：喜欢没商量，虽然没汪峰摇滚，但不沙哑的存在合我胃口，何况小姑娘这
: 么萌这么可爱。
: 2，罗琦：唱功没的说，希望听她多唱几首。听她唱歌的机会太少了。
: 3，韦唯：虽然老调，但这么好听的中音难得听到
: 4，曹格：喜欢不同于赵传的味道，很好听，被淘汰实在可惜
: 5，周笔畅：烦人的形象，歌还别致
: 6，张宇：不是我的菜，听着有点憋闷
: 7，韩磊：不喜欢就是不喜欢，真希望被淘汰的是他，没惊喜太老套，都是一个劲儿

w*g2017-07-25 07:07

12 楼

C++的话我用simple-web-server和json11
python的话就是flask和django。

【在 L****8 的大作中提到】

: 有啥推荐的开源库？

F*s2017-07-25 07:07

13 楼

十年了，很多当时的帖子历历在目，绝大多删掉了，不过当时的股版情绪还记得很清楚
，股市轮回百年不变。

L*82017-07-25 07:07

14 楼

Qt的network库如何？

【在 w***g 的大作中提到】

: C++的话我用simple-web-server和json11
: python的话就是flask和django。

d*e2017-07-25 07:07

15 楼

前辈能否总结下当时的好贴或者自己的经验？
现在的蝌蚪青蛙都是初生牛犊不怕虎

【在 F****s 的大作中提到】

: 十年了，很多当时的帖子历历在目，绝大多删掉了，不过当时的股版情绪还记得很清楚
: ，股市轮回百年不变。

s*k2017-07-25 07:07

16 楼

大牛，在分布式机器学习上倒是gRPC用的多？

【在 w***g 的大作中提到】

: 我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
: 主要是好在HTTP是标准，服务器/客户的库和工具都很多。
: 并且协议非常flexible，可以很容易地往里面加调试用的内容。
: 那些特定协议我觉得主要是性能好。

p*o2017-07-25 07:07

17 楼

试图理解大户的思路，但是不要学他们。小家小户的幸福日子他们未必有。认清自己是
非专业小户，投资不是投机，放过自己。

l*m2017-07-25 07:07

18 楼

最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个video stream起
一个TF session, 用grpc开了一个inference server共享。好处是cpu和带宽的利用率
比较高。TF本来就是一堆proto，这样至少减少一次转换。
grpc在自己的机器间用没问题，但最好不要用于开放的客户端。因为还很不成熟，我发
几个恶意的requests, 居然c++的server就crash了!!! 这个在web中，基本不会发生。
grpc是基于http/2，http/2也很不成熟, 而且是binary不是text，前面提到的crash就
很有可能因为http/2 header的异常处理有问题。总之合作的正常使用是ok的

【在 s********k 的大作中提到】

: 大牛，在分布式机器学习上倒是gRPC用的多？

p*o2017-07-25 07:07

19 楼

噢，突然明白你为什么翻出来这个了，是因为08-10相对09-03？

：十年了，很多当时的帖子历历在目，绝大多删掉了，不过当时的股版情绪还记得很清
楚，股市轮回百年不变。

d*r2017-07-25 07:07

20 楼

"grpc在自己的机器间用没问题，但最好不要用于开放的客户端。因为还很不成熟"
这么脆弱

【在 l*******m 的大作中提到】

: 最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个video stream起
: 一个TF session, 用grpc开了一个inference server共享。好处是cpu和带宽的利用率
: 比较高。TF本来就是一堆proto，这样至少减少一次转换。
: grpc在自己的机器间用没问题，但最好不要用于开放的客户端。因为还很不成熟，我发
: 几个恶意的requests, 居然c++的server就crash了!!! 这个在web中，基本不会发生。
: grpc是基于http/2，http/2也很不成熟, 而且是binary不是text，前面提到的crash就
: 很有可能因为http/2 header的异常处理有问题。总之合作的正常使用是ok的

F*s2017-07-25 07:07

21 楼

没有具体对比，时代不同了，现在去对比上个世纪80年代，20年代，都没有意义了。

【在 p*******o 的大作中提到】

: 噢，突然明白你为什么翻出来这个了，是因为08-10相对09-03？
:
: ：十年了，很多当时的帖子历历在目，绝大多删掉了，不过当时的股版情绪还记得很清
: 楚，股市轮回百年不变。

w*g2017-07-25 07:07

22 楼

分布式机器学习轮子内部的东西你去操心他干嘛？

【在 s********k 的大作中提到】

: 大牛，在分布式机器学习上倒是gRPC用的多？

w*g2017-07-25 07:07

23 楼

你这个太牛了，要不open-source了造福下大家？
顺便请教下，你的inference server是GPU吗？是否用到了类似task-queue这种
机制？电费咋样？

【在 l*******m 的大作中提到】

: 最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个video stream起
: 一个TF session, 用grpc开了一个inference server共享。好处是cpu和带宽的利用率
: 比较高。TF本来就是一堆proto，这样至少减少一次转换。
: grpc在自己的机器间用没问题，但最好不要用于开放的客户端。因为还很不成熟，我发
: 几个恶意的requests, 居然c++的server就crash了!!! 这个在web中，基本不会发生。
: grpc是基于http/2，http/2也很不成熟, 而且是binary不是text，前面提到的crash就
: 很有可能因为http/2 header的异常处理有问题。总之合作的正常使用是ok的

k*i2017-07-25 07:07

24 楼

inference server 没狗倒，类似
https://github.com/dmlc/ps-lite 吗？

：最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个video stream
起一个TF session, 用grpc开了一个inference server共享。好处是cpu和带宽的利用率
：比较高。TF本来就是一堆proto，这样至少减少一次转换。

a92017-07-25 07:07

25 楼

xml还是算了

说内

【在 w***g 的大作中提到】

: 我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
: 主要是好在HTTP是标准，服务器/客户的库和工具都很多。
: 并且协议非常flexible，可以很容易地往里面加调试用的内容。
: 那些特定协议我觉得主要是性能好。

s*k2017-07-25 07:07

26 楼

应该说很多公司内部：比如ML和其他service之间都在用gRPC，可能就开放给外面的API
不用

【在 w***g 的大作中提到】

: 分布式机器学习轮子内部的东西你去操心他干嘛？

s*k2017-07-25 07:07

27 楼

大牛啊，这个inference server共享的意思是所有的video都从一个server拿参数做
inference？还是所有video都送到一个server上去做inference？

【在 l*******m 的大作中提到】

: 最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个video stream起
: 一个TF session, 用grpc开了一个inference server共享。好处是cpu和带宽的利用率
: 比较高。TF本来就是一堆proto，这样至少减少一次转换。
: grpc在自己的机器间用没问题，但最好不要用于开放的客户端。因为还很不成熟，我发
: 几个恶意的requests, 居然c++的server就crash了!!! 这个在web中，基本不会发生。
: grpc是基于http/2，http/2也很不成熟, 而且是binary不是text，前面提到的crash就
: 很有可能因为http/2 header的异常处理有问题。总之合作的正常使用是ok的

s*e2017-07-25 07:07

28 楼

tensorflow serving 里面提到batch processing with configurable latency。
楼主如果用gpu也是这个思路么？用什么存那个batch？

【在 l*******m 的大作中提到】

: 最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个video stream起
: 一个TF session, 用grpc开了一个inference server共享。好处是cpu和带宽的利用率
: 比较高。TF本来就是一堆proto，这样至少减少一次转换。
: grpc在自己的机器间用没问题，但最好不要用于开放的客户端。因为还很不成熟，我发
: 几个恶意的requests, 居然c++的server就crash了!!! 这个在web中，基本不会发生。
: grpc是基于http/2，http/2也很不成熟, 而且是binary不是text，前面提到的crash就
: 很有可能因为http/2 header的异常处理有问题。总之合作的正常使用是ok的

s*e2017-07-25 07:07

29 楼

大牛可以分享下文件交换的gPRC代码要怎么写？
如果不用RPC，是不是可以考虑redis等pub/sub services当shared memory来用？
现在要交换的文件都是图片， 1MB 到6MB一张，最后希望做到detection和
classification一套下来做到接近real time(30fps),越接近越好，如果还有剩余性能
就做tracking。模型已经train好了
单GPU做IPC肯定是不满足性能要求的，被迫要上多GPU或者多机，单机多GPU能搞掂最好
，jetson 能搞出来更好
还是有整套方案可以介绍？ tensorflow serving 那套感觉目前比较多坑，kubernete
https://medium.com/zendesk-engineering/how-zendesk-serves-tensorflow-models-
in-production-751ee22f0f4b
而且这个项目有硬性要求还不能上公共云

【在 w***g 的大作中提到】

: 我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
: 主要是好在HTTP是标准，服务器/客户的库和工具都很多。
: 并且协议非常flexible，可以很容易地往里面加调试用的内容。
: 那些特定协议我觉得主要是性能好。

s*e2017-07-25 07:07

30 楼

有整套方案可以介绍？ tensorflow serving 那套感觉目前比较多坑，kubernete
https://medium.com/zendesk-engineering/how-zendesk-serves-tensorflow-models-
in-production-751ee22f0f4b
而且这个项目有硬性要求还不能上公共云

【在 l*******m 的大作中提到】

: 最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个video stream起
: 一个TF session, 用grpc开了一个inference server共享。好处是cpu和带宽的利用率
: 比较高。TF本来就是一堆proto，这样至少减少一次转换。
: grpc在自己的机器间用没问题，但最好不要用于开放的客户端。因为还很不成熟，我发
: 几个恶意的requests, 居然c++的server就crash了!!! 这个在web中，基本不会发生。
: grpc是基于http/2，http/2也很不成熟, 而且是binary不是text，前面提到的crash就
: 很有可能因为http/2 header的异常处理有问题。总之合作的正常使用是ok的

s*e2017-07-25 07:07

31 楼

【在 l*******m 的大作中提到】

: 最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个video stream起
: 一个TF session, 用grpc开了一个inference server共享。好处是cpu和带宽的利用率
: 比较高。TF本来就是一堆proto，这样至少减少一次转换。
: grpc在自己的机器间用没问题，但最好不要用于开放的客户端。因为还很不成熟，我发
: 几个恶意的requests, 居然c++的server就crash了!!! 这个在web中，基本不会发生。
: grpc是基于http/2，http/2也很不成熟, 而且是binary不是text，前面提到的crash就
: 很有可能因为http/2 header的异常处理有问题。总之合作的正常使用是ok的

n*p2017-07-25 07:07

32 楼

gRPC just another RPC. Remind me RMI and CORBA, no benefit to move from REST
to it.

【在 s********k 的大作中提到】

: 看到很多都在从REST API转向gRPC，是因为JSON的格式太繁琐？protobuf好？还是说内
: 部应用不需要expose interface，gRPC更有效率？

s*22017-07-25 07:07

33 楼

grpc支持bidirectional streaming

kubernete
models-

【在 s*****e 的大作中提到】

: 大牛可以分享下文件交换的gPRC代码要怎么写？
: 如果不用RPC，是不是可以考虑redis等pub/sub services当shared memory来用？
: 现在要交换的文件都是图片， 1MB 到6MB一张，最后希望做到detection和
: classification一套下来做到接近real time(30fps),越接近越好，如果还有剩余性能
: 就做tracking。模型已经train好了
: 单GPU做IPC肯定是不满足性能要求的，被迫要上多GPU或者多机，单机多GPU能搞掂最好
: ，jetson 能搞出来更好
: 还是有整套方案可以介绍？ tensorflow serving 那套感觉目前比较多坑，kubernete
: https://medium.com/zendesk-engineering/how-zendesk-serves-tensorflow-models-
: in-production-751ee22f0f4b

s*e2017-07-25 07:07

34 楼

我有3个python process，其中两个会一秒钟内反复找第三个process要图片。
目前我使用flask的restful api,把opencv里面读出来的图片base64 encode成string再
发。但是现在response是blocking的.如果两个python process同时request,就是一个
一个地回复,太慢了.
有方案介绍么？我是否应该看看tornado?

【在 w***g 的大作中提到】

: 我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
: 主要是好在HTTP是标准，服务器/客户的库和工具都很多。
: 并且协议非常flexible，可以很容易地往里面加调试用的内容。
: 那些特定协议我觉得主要是性能好。

w*g2017-07-25 07:07

35 楼

stack overflow现找了一个. Tornado不值得看. 你的时间都耗在了图像处理上,
这点时间靠tornado根本省不回来.
if __name__ == '__main__':
app.run(threaded=True)
# Alternately
# app.run(processes=3)

【在 s*****e 的大作中提到】

: 我有3个python process，其中两个会一秒钟内反复找第三个process要图片。
: 目前我使用flask的restful api,把opencv里面读出来的图片base64 encode成string再
: 发。但是现在response是blocking的.如果两个python process同时request,就是一个
: 一个地回复,太慢了.
: 有方案介绍么？我是否应该看看tornado?

d*r2017-07-25 07:07

36 楼

异步任务可以用 celery

【在 s*****e 的大作中提到】

: 我有3个python process，其中两个会一秒钟内反复找第三个process要图片。
: 目前我使用flask的restful api,把opencv里面读出来的图片base64 encode成string再
: 发。但是现在response是blocking的.如果两个python process同时request,就是一个
: 一个地回复,太慢了.
: 有方案介绍么？我是否应该看看tornado?

s*e2017-07-25 07:07

37 楼

谢谢！
由于GIL的缘故，我是不是应该用app.run(processes=3)而不要用thread？
话说我现在用restful BASE64 encode成string传图片的方法合理么？ local network
传，小图片1MB以下的 25MB/S， 4MB-6mb的只有2MB/s。我现在是单张单张地发。我
是不是应该写raw socket或者什么办法来做图片收发这个事情？这里的delay还是不小
的，gRPC default只能支持4MB

【在 w***g 的大作中提到】

: stack overflow现找了一个. Tornado不值得看. 你的时间都耗在了图像处理上,
: 这点时间靠tornado根本省不回来.
: if __name__ == '__main__':
: app.run(threaded=True)
: # Alternately
: # app.run(processes=3)

s*k2017-07-25 07:07

38 楼

GIL的多个process不会影响吧，还有就是换python 3，或者coroutine，不过要是
computation heavy那就不选Python就是

network

【在 s*****e 的大作中提到】

: 谢谢！
: 由于GIL的缘故，我是不是应该用app.run(processes=3)而不要用thread？
: 话说我现在用restful BASE64 encode成string传图片的方法合理么？ local network
: 传，小图片1MB以下的 25MB/S， 4MB-6mb的只有2MB/s。我现在是单张单张地发。我
: 是不是应该写raw socket或者什么办法来做图片收发这个事情？这里的delay还是不小
: 的，gRPC default只能支持4MB

s*k2017-07-25 07:07

39 楼

看到很多都在从REST API转向gRPC，是因为JSON的格式太繁琐？protobuf好？还是说内
部应用不需要expose interface，gRPC更有效率？

w*g2017-07-25 07:07

40 楼

我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
主要是好在HTTP是标准，服务器/客户的库和工具都很多。
并且协议非常flexible，可以很容易地往里面加调试用的内容。
那些特定协议我觉得主要是性能好。

【在 s********k 的大作中提到】

: 看到很多都在从REST API转向gRPC，是因为JSON的格式太繁琐？protobuf好？还是说内
: 部应用不需要expose interface，gRPC更有效率？

L*82017-07-25 07:07

41 楼

有啥推荐的开源库？

【在 w***g 的大作中提到】

: 我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
: 主要是好在HTTP是标准，服务器/客户的库和工具都很多。
: 并且协议非常flexible，可以很容易地往里面加调试用的内容。
: 那些特定协议我觉得主要是性能好。

w*g2017-07-25 07:07

42 楼

C++的话我用simple-web-server和json11
python的话就是flask和django。

【在 L****8 的大作中提到】

: 有啥推荐的开源库？

L*82017-07-25 07:07

43 楼

Qt的network库如何？

【在 w***g 的大作中提到】

: C++的话我用simple-web-server和json11
: python的话就是flask和django。

s*k2017-07-25 07:07

44 楼

大牛，在分布式机器学习上倒是gRPC用的多？

【在 w***g 的大作中提到】

: 我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
: 主要是好在HTTP是标准，服务器/客户的库和工具都很多。
: 并且协议非常flexible，可以很容易地往里面加调试用的内容。
: 那些特定协议我觉得主要是性能好。

l*m2017-07-25 07:07

45 楼

最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个video stream起
一个TF session, 用grpc开了一个inference server共享。好处是cpu和带宽的利用率
比较高。TF本来就是一堆proto，这样至少减少一次转换。
grpc在自己的机器间用没问题，但最好不要用于开放的客户端。因为还很不成熟，我发
几个恶意的requests, 居然c++的server就crash了!!! 这个在web中，基本不会发生。
grpc是基于http/2，http/2也很不成熟, 而且是binary不是text，前面提到的crash就
很有可能因为http/2 header的异常处理有问题。总之合作的正常使用是ok的

【在 s********k 的大作中提到】

: 大牛，在分布式机器学习上倒是gRPC用的多？

d*r2017-07-25 07:07

46 楼

"grpc在自己的机器间用没问题，但最好不要用于开放的客户端。因为还很不成熟"
这么脆弱

【在 l*******m 的大作中提到】

: 最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个video stream起
: 一个TF session, 用grpc开了一个inference server共享。好处是cpu和带宽的利用率
: 比较高。TF本来就是一堆proto，这样至少减少一次转换。
: grpc在自己的机器间用没问题，但最好不要用于开放的客户端。因为还很不成熟，我发
: 几个恶意的requests, 居然c++的server就crash了!!! 这个在web中，基本不会发生。
: grpc是基于http/2，http/2也很不成熟, 而且是binary不是text，前面提到的crash就
: 很有可能因为http/2 header的异常处理有问题。总之合作的正常使用是ok的

w*g2017-07-25 07:07

47 楼

分布式机器学习轮子内部的东西你去操心他干嘛？

【在 s********k 的大作中提到】

: 大牛，在分布式机器学习上倒是gRPC用的多？

w*g2017-07-25 07:07

48 楼

你这个太牛了，要不open-source了造福下大家？
顺便请教下，你的inference server是GPU吗？是否用到了类似task-queue这种
机制？电费咋样？

【在 l*******m 的大作中提到】

: 最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个video stream起
: 一个TF session, 用grpc开了一个inference server共享。好处是cpu和带宽的利用率
: 比较高。TF本来就是一堆proto，这样至少减少一次转换。
: grpc在自己的机器间用没问题，但最好不要用于开放的客户端。因为还很不成熟，我发
: 几个恶意的requests, 居然c++的server就crash了!!! 这个在web中，基本不会发生。
: grpc是基于http/2，http/2也很不成熟, 而且是binary不是text，前面提到的crash就
: 很有可能因为http/2 header的异常处理有问题。总之合作的正常使用是ok的

k*i2017-07-25 07:07

49 楼

inference server 没狗倒，类似
https://github.com/dmlc/ps-lite 吗？

：最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个video stream
起一个TF session, 用grpc开了一个inference server共享。好处是cpu和带宽的利用率
：比较高。TF本来就是一堆proto，这样至少减少一次转换。

a92017-07-25 07:07

50 楼

xml还是算了

说内

【在 w***g 的大作中提到】

: 我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
: 主要是好在HTTP是标准，服务器/客户的库和工具都很多。
: 并且协议非常flexible，可以很容易地往里面加调试用的内容。
: 那些特定协议我觉得主要是性能好。

s*k2017-07-25 07:07

51 楼

应该说很多公司内部：比如ML和其他service之间都在用gRPC，可能就开放给外面的API
不用

【在 w***g 的大作中提到】

: 分布式机器学习轮子内部的东西你去操心他干嘛？

s*k2017-07-25 07:07

52 楼

大牛啊，这个inference server共享的意思是所有的video都从一个server拿参数做
inference？还是所有video都送到一个server上去做inference？

【在 l*******m 的大作中提到】

: 最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个video stream起
: 一个TF session, 用grpc开了一个inference server共享。好处是cpu和带宽的利用率
: 比较高。TF本来就是一堆proto，这样至少减少一次转换。
: grpc在自己的机器间用没问题，但最好不要用于开放的客户端。因为还很不成熟，我发
: 几个恶意的requests, 居然c++的server就crash了!!! 这个在web中，基本不会发生。
: grpc是基于http/2，http/2也很不成熟, 而且是binary不是text，前面提到的crash就
: 很有可能因为http/2 header的异常处理有问题。总之合作的正常使用是ok的

s*e2017-07-25 07:07

53 楼

tensorflow serving 里面提到batch processing with configurable latency。
楼主如果用gpu也是这个思路么？用什么存那个batch？

【在 l*******m 的大作中提到】

: 最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个video stream起
: 一个TF session, 用grpc开了一个inference server共享。好处是cpu和带宽的利用率
: 比较高。TF本来就是一堆proto，这样至少减少一次转换。
: grpc在自己的机器间用没问题，但最好不要用于开放的客户端。因为还很不成熟，我发
: 几个恶意的requests, 居然c++的server就crash了!!! 这个在web中，基本不会发生。
: grpc是基于http/2，http/2也很不成熟, 而且是binary不是text，前面提到的crash就
: 很有可能因为http/2 header的异常处理有问题。总之合作的正常使用是ok的

s*e2017-07-25 07:07

54 楼

大牛可以分享下文件交换的gPRC代码要怎么写？
如果不用RPC，是不是可以考虑redis等pub/sub services当shared memory来用？
现在要交换的文件都是图片， 1MB 到6MB一张，最后希望做到detection和
classification一套下来做到接近real time(30fps),越接近越好，如果还有剩余性能
就做tracking。模型已经train好了
单GPU做IPC肯定是不满足性能要求的，被迫要上多GPU或者多机，单机多GPU能搞掂最好
，jetson 能搞出来更好
还是有整套方案可以介绍？ tensorflow serving 那套感觉目前比较多坑，kubernete
https://medium.com/zendesk-engineering/how-zendesk-serves-tensorflow-models-
in-production-751ee22f0f4b
而且这个项目有硬性要求还不能上公共云

【在 w***g 的大作中提到】

: 我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
: 主要是好在HTTP是标准，服务器/客户的库和工具都很多。
: 并且协议非常flexible，可以很容易地往里面加调试用的内容。
: 那些特定协议我觉得主要是性能好。

s*e2017-07-25 07:07

55 楼

有整套方案可以介绍？ tensorflow serving 那套感觉目前比较多坑，kubernete
https://medium.com/zendesk-engineering/how-zendesk-serves-tensorflow-models-
in-production-751ee22f0f4b
而且这个项目有硬性要求还不能上公共云

【在 l*******m 的大作中提到】

: 最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个video stream起
: 一个TF session, 用grpc开了一个inference server共享。好处是cpu和带宽的利用率
: 比较高。TF本来就是一堆proto，这样至少减少一次转换。
: grpc在自己的机器间用没问题，但最好不要用于开放的客户端。因为还很不成熟，我发
: 几个恶意的requests, 居然c++的server就crash了!!! 这个在web中，基本不会发生。
: grpc是基于http/2，http/2也很不成熟, 而且是binary不是text，前面提到的crash就
: 很有可能因为http/2 header的异常处理有问题。总之合作的正常使用是ok的

s*e2017-07-25 07:07

56 楼

【在 l*******m 的大作中提到】

: 最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个video stream起
: 一个TF session, 用grpc开了一个inference server共享。好处是cpu和带宽的利用率
: 比较高。TF本来就是一堆proto，这样至少减少一次转换。
: grpc在自己的机器间用没问题，但最好不要用于开放的客户端。因为还很不成熟，我发
: 几个恶意的requests, 居然c++的server就crash了!!! 这个在web中，基本不会发生。
: grpc是基于http/2，http/2也很不成熟, 而且是binary不是text，前面提到的crash就
: 很有可能因为http/2 header的异常处理有问题。总之合作的正常使用是ok的

n*p2017-07-25 07:07

57 楼

gRPC just another RPC. Remind me RMI and CORBA, no benefit to move from REST
to it.

【在 s********k 的大作中提到】

: 看到很多都在从REST API转向gRPC，是因为JSON的格式太繁琐？protobuf好？还是说内
: 部应用不需要expose interface，gRPC更有效率？

s*22017-07-25 07:07

58 楼

grpc支持bidirectional streaming

kubernete
models-

【在 s*****e 的大作中提到】

: 大牛可以分享下文件交换的gPRC代码要怎么写？
: 如果不用RPC，是不是可以考虑redis等pub/sub services当shared memory来用？
: 现在要交换的文件都是图片， 1MB 到6MB一张，最后希望做到detection和
: classification一套下来做到接近real time(30fps),越接近越好，如果还有剩余性能
: 就做tracking。模型已经train好了
: 单GPU做IPC肯定是不满足性能要求的，被迫要上多GPU或者多机，单机多GPU能搞掂最好
: ，jetson 能搞出来更好
: 还是有整套方案可以介绍？ tensorflow serving 那套感觉目前比较多坑，kubernete
: https://medium.com/zendesk-engineering/how-zendesk-serves-tensorflow-models-
: in-production-751ee22f0f4b

s*e2017-07-25 07:07

59 楼

我有3个python process，其中两个会一秒钟内反复找第三个process要图片。
目前我使用flask的restful api,把opencv里面读出来的图片base64 encode成string再
发。但是现在response是blocking的.如果两个python process同时request,就是一个
一个地回复,太慢了.
有方案介绍么？我是否应该看看tornado?

【在 w***g 的大作中提到】

: 我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
: 主要是好在HTTP是标准，服务器/客户的库和工具都很多。
: 并且协议非常flexible，可以很容易地往里面加调试用的内容。
: 那些特定协议我觉得主要是性能好。

w*g2017-07-25 07:07

60 楼

stack overflow现找了一个. Tornado不值得看. 你的时间都耗在了图像处理上,
这点时间靠tornado根本省不回来.
if __name__ == '__main__':
app.run(threaded=True)
# Alternately
# app.run(processes=3)

【在 s*****e 的大作中提到】

: 我有3个python process，其中两个会一秒钟内反复找第三个process要图片。
: 目前我使用flask的restful api,把opencv里面读出来的图片base64 encode成string再
: 发。但是现在response是blocking的.如果两个python process同时request,就是一个
: 一个地回复,太慢了.
: 有方案介绍么？我是否应该看看tornado?

d*r2017-07-25 07:07

61 楼

异步任务可以用 celery

【在 s*****e 的大作中提到】

: 我有3个python process，其中两个会一秒钟内反复找第三个process要图片。
: 目前我使用flask的restful api,把opencv里面读出来的图片base64 encode成string再
: 发。但是现在response是blocking的.如果两个python process同时request,就是一个
: 一个地回复,太慢了.
: 有方案介绍么？我是否应该看看tornado?

s*e2017-07-25 07:07

62 楼

谢谢！
由于GIL的缘故，我是不是应该用app.run(processes=3)而不要用thread？
话说我现在用restful BASE64 encode成string传图片的方法合理么？ local network
传，小图片1MB以下的 25MB/S， 4MB-6mb的只有2MB/s。我现在是单张单张地发。我
是不是应该写raw socket或者什么办法来做图片收发这个事情？这里的delay还是不小
的，gRPC default只能支持4MB

【在 w***g 的大作中提到】

: stack overflow现找了一个. Tornado不值得看. 你的时间都耗在了图像处理上,
: 这点时间靠tornado根本省不回来.
: if __name__ == '__main__':
: app.run(threaded=True)
: # Alternately
: # app.run(processes=3)

s*k2017-07-25 07:07

63 楼

GIL的多个process不会影响吧，还有就是换python 3，或者coroutine，不过要是
computation heavy那就不选Python就是

network

【在 s*****e 的大作中提到】

: 谢谢！
: 由于GIL的缘故，我是不是应该用app.run(processes=3)而不要用thread？
: 话说我现在用restful BASE64 encode成string传图片的方法合理么？ local network
: 传，小图片1MB以下的 25MB/S， 4MB-6mb的只有2MB/s。我现在是单张单张地发。我
: 是不是应该写raw socket或者什么办法来做图片收发这个事情？这里的delay还是不小
: 的，gRPC default只能支持4MB

f*22017-07-25 07:07

64 楼

gRPC现在成熟到可以开放给客户了吗？

: gRPC just another RPC. Remind me RMI and CORBA, no benefit to move
from REST

: to it.

【在 n***p 的大作中提到】

: gRPC just another RPC. Remind me RMI and CORBA, no benefit to move from REST
: to it.