s********k
发帖数: 6180 | 1 看到很多都在从REST API转向gRPC，是因为JSON的格式太繁琐？protobuf好？还是说内
部应用不需要expose interface，gRPC更有效率？ |
w***g
发帖数: 5958 | 2 我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
主要是好在HTTP是标准，服务器/客户的库和工具都很多。
并且协议非常flexible，可以很容易地往里面加调试用的内容。
那些特定协议我觉得主要是性能好。
【在 s********k 的大作中提到】
: 看到很多都在从REST API转向gRPC，是因为JSON的格式太繁琐？protobuf好？还是说内
: 部应用不需要expose interface，gRPC更有效率？
|
L****8
发帖数: 3938 | 3 有啥推荐的开源库？
【在 w***g 的大作中提到】
: 我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
: 主要是好在HTTP是标准，服务器/客户的库和工具都很多。
: 并且协议非常flexible，可以很容易地往里面加调试用的内容。
: 那些特定协议我觉得主要是性能好。
|
w***g
发帖数: 5958 | 4 C++的话我用simple-web-server和json11
python的话就是flask和django。
【在 L****8 的大作中提到】
: 有啥推荐的开源库？
|
L****8
发帖数: 3938 | 5 Qt的network库 如何？
【在 w***g 的大作中提到】
: C++的话我用simple-web-server和json11
: python的话就是flask和django。
|
s********k
发帖数: 6180 | 6 大牛，在分布式机器学习上倒是gRPC用的多？
【在 w***g 的大作中提到】
: 我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
: 主要是好在HTTP是标准，服务器/客户的库和工具都很多。
: 并且协议非常flexible，可以很容易地往里面加调试用的内容。
: 那些特定协议我觉得主要是性能好。
|
l*******m
发帖数: 1096 | 7 最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个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*******r
发帖数: 3299 | 8 "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***g
发帖数: 5958 | 9 分布式机器学习轮子内部的东西你去操心他干嘛？
【在 s********k 的大作中提到】
: 大牛，在分布式机器学习上倒是gRPC用的多？
|
w***g
发帖数: 5958 | 10 你这个太牛了，要不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****i
发帖数: 101 | 11 inference server 没狗倒，类似
https://github.com/dmlc/ps-lite 吗？
：最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个video stream
起一个TF session, 用grpc开了一个inference server共享。好处是cpu和带宽的利用率
：比较高。TF本来就是一堆proto，这样至少减少一次转换。 |
a9
发帖数: 21638 | 12 xml还是算了
说内
【在 w***g 的大作中提到】
: 我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
: 主要是好在HTTP是标准，服务器/客户的库和工具都很多。
: 并且协议非常flexible，可以很容易地往里面加调试用的内容。
: 那些特定协议我觉得主要是性能好。
|
s********k
发帖数: 6180 | 13 应该说很多公司内部：比如ML和其他service之间都在用gRPC，可能就开放给外面的API
不用
【在 w***g 的大作中提到】
: 分布式机器学习轮子内部的东西你去操心他干嘛？
|
s********k
发帖数: 6180 | 14 大牛啊，这个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*****e
发帖数: 115 | 15 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*****e
发帖数: 115 | 16 大牛可以分享下文件交换的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*****e
发帖数: 115 | 17 有整套方案可以介绍？ 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*****e
发帖数: 115 | 18
【在 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***p
发帖数: 110 | 19 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*******2
发帖数: 39 | 20 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*****e
发帖数: 115 | 21 我有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***g
发帖数: 5958 | 22 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*******r
发帖数: 3299 | 23 异步任务可以用 celery
【在 s*****e 的大作中提到】
: 我有3个python process，其中两个会一秒钟内反复找第三个process要图片。
: 目前我使用flask的restful api,把opencv里面读出来的图片base64 encode成string再
: 发。但是现在response是blocking的.如果两个python process同时request,就是一个
: 一个地回复,太慢了.
: 有方案介绍么？我是否应该看看tornado?
|
s*****e
发帖数: 115 | 24 谢谢！
由于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********k
发帖数: 6180 | 25 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********k
发帖数: 6180 | 26 看到很多都在从REST API转向gRPC，是因为JSON的格式太繁琐？protobuf好？还是说内
部应用不需要expose interface，gRPC更有效率？ |
w***g
发帖数: 5958 | 27 我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
主要是好在HTTP是标准，服务器/客户的库和工具都很多。
并且协议非常flexible，可以很容易地往里面加调试用的内容。
那些特定协议我觉得主要是性能好。
【在 s********k 的大作中提到】
: 看到很多都在从REST API转向gRPC，是因为JSON的格式太繁琐？protobuf好？还是说内
: 部应用不需要expose interface，gRPC更有效率？
|
L****8
发帖数: 3938 | 28 有啥推荐的开源库？
【在 w***g 的大作中提到】
: 我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
: 主要是好在HTTP是标准，服务器/客户的库和工具都很多。
: 并且协议非常flexible，可以很容易地往里面加调试用的内容。
: 那些特定协议我觉得主要是性能好。
|
w***g
发帖数: 5958 | 29 C++的话我用simple-web-server和json11
python的话就是flask和django。
【在 L****8 的大作中提到】
: 有啥推荐的开源库？
|
L****8
发帖数: 3938 | 30 Qt的network库 如何？
【在 w***g 的大作中提到】
: C++的话我用simple-web-server和json11
: python的话就是flask和django。
|
|
|
s********k
发帖数: 6180 | 31 大牛，在分布式机器学习上倒是gRPC用的多？
【在 w***g 的大作中提到】
: 我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
: 主要是好在HTTP是标准，服务器/客户的库和工具都很多。
: 并且协议非常flexible，可以很容易地往里面加调试用的内容。
: 那些特定协议我觉得主要是性能好。
|
l*******m
发帖数: 1096 | 32 最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个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*******r
发帖数: 3299 | 33 "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***g
发帖数: 5958 | 34 分布式机器学习轮子内部的东西你去操心他干嘛？
【在 s********k 的大作中提到】
: 大牛，在分布式机器学习上倒是gRPC用的多？
|
w***g
发帖数: 5958 | 35 你这个太牛了，要不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****i
发帖数: 101 | 36 inference server 没狗倒，类似
https://github.com/dmlc/ps-lite 吗？
：最近我把自己家的安防系统升级了，全都深度学习了。为了避免每一个video stream
起一个TF session, 用grpc开了一个inference server共享。好处是cpu和带宽的利用率
：比较高。TF本来就是一堆proto，这样至少减少一次转换。 |
a9
发帖数: 21638 | 37 xml还是算了
说内
【在 w***g 的大作中提到】
: 我从RPC到xmlRPC，一直用到thrift/gRPC。最后觉得rest API最好。
: 主要是好在HTTP是标准，服务器/客户的库和工具都很多。
: 并且协议非常flexible，可以很容易地往里面加调试用的内容。
: 那些特定协议我觉得主要是性能好。
|
s********k
发帖数: 6180 | 38 应该说很多公司内部：比如ML和其他service之间都在用gRPC，可能就开放给外面的API
不用
【在 w***g 的大作中提到】
: 分布式机器学习轮子内部的东西你去操心他干嘛？
|
s********k
发帖数: 6180 | 39 大牛啊，这个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*****e
发帖数: 115 | 40 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*****e
发帖数: 115 | 41 大牛可以分享下文件交换的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*****e
发帖数: 115 | 42 有整套方案可以介绍？ 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*****e
发帖数: 115 | 43
【在 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***p
发帖数: 110 | 44 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*******2
发帖数: 39 | 45 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*****e
发帖数: 115 | 46 我有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***g
发帖数: 5958 | 47 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*******r
发帖数: 3299 | 48 异步任务可以用 celery
【在 s*****e 的大作中提到】
: 我有3个python process，其中两个会一秒钟内反复找第三个process要图片。
: 目前我使用flask的restful api,把opencv里面读出来的图片base64 encode成string再
: 发。但是现在response是blocking的.如果两个python process同时request,就是一个
: 一个地回复,太慢了.
: 有方案介绍么？我是否应该看看tornado?
|
s*****e
发帖数: 115 | 49 谢谢！
由于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********k
发帖数: 6180 | 50 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******2
发帖数: 2455 | 51 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.
|
