Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gunicorn + thriftpy2 使用上的几点疑问 #65

Closed
victordudu1121 opened this issue Jul 7, 2019 · 12 comments
Closed

gunicorn + thriftpy2 使用上的几点疑问 #65

victordudu1121 opened this issue Jul 7, 2019 · 12 comments

Comments

@victordudu1121
Copy link

您好! 请问关于使用thriftpy2 + gunicorn_thrift + gevent worker-class 使用场景来再生产环境里,增强thriftpy server吞吐性能使用场景,我遇到如下几个问题,特来请教大神:
(1) 对于使用thrfitpy2框架,并业务handler里,处理一条请求里有较多rpc访问,我理解上述 gunicorn 多worker进程 + 每个worker使用gevent类型,应该是性能最佳的组合? 当然我没有实践,跟@ethe 确认
(2) 我看worker-class = gevent 只适用于protocol=TBinaryProtocol 和 transport=TBufferedTransport, transport不支持TFramedTransport么?
(3) 我原来使用thriftpy2 make_server接口,采用的TthreadServer, 多线程模式并发处理请求,业务处理handler里,需要在处理并发请求时,加锁,做一些同步处理,这种场景,改为gunicorn_thrift fork多worker进程模式,应当如何保障在多个worker进程处理请求时,共享一个全局的进程锁,多worker同步了?

@ethe 能否在百忙之中,及时帮我们答疑解惑了? 万分感谢! 以及是否方便微信联系了? 我们在较大规模应用thriftpy2 以及相关组件

@ethe
Copy link
Member

ethe commented Jul 7, 2019

(1) 是的,这是最佳实践
(2) gunicorn_thrift 目前不支持 TFramedTransport,推荐使用 TBufferedTransport
(3) 可以使用 Redis, ETCD, Zookeeper 等其它工具实现锁

微信:394519475

@victordudu1121
Copy link
Author

victordudu1121 commented Jul 7, 2019

(1) 是的,这是最佳实践
(2) gunicorn_thrift 目前不支持 TFramedTransport,推荐使用 TBufferedTransport
(3) 可以使用 Redis, ETCD, Zookeeper 等其它工具实现锁

微信:394519475

@ethe 非常感谢你的replay. 收益匪浅!
对于第(3)点,使用redis 实现 多worker进程之间的同步锁,是否会大幅降低gunicorn_thrift处理并发的性能了? 毕竟多了频繁的redis网络交互?
是否可以想办法使用mutilprocess.Lock 原生lock来实现gunicorn_thrift pre_fork 出的多个work子进程共享这个lock对象,实现同步了? 我试了一哈,在app.py里,定义一个如下的全局进程锁,然后在app业务handler里去用该进程锁对象互斥,是不生效的? 不知@ethe有没有更好的建议。
我的示例代码如下app.py:

image

@ethe
Copy link
Member

ethe commented Jul 8, 2019

你要在跨进程间用锁性能就好不了。mutilprocess 基本只能做单机。

@victordudu1121
Copy link
Author

你要在跨进程间用锁性能就好不了。mutilprocess 基本只能做单机。

就是单机的, 我在单机上 用gunicorn_thrift启动一个thriftpy2 server实例, 开启多个worker进程,一个实例的多个worker进程之间,在处理业务handler里部分操作需要同步。 并不需要跨主机(或者跨server实例)

@ethe 有什么好的建议么? 我尝试在app.py 里定义一个全局的mutilprocess.Lock()对象,然后在handler里处理请求是使用这个锁同步,实际测试结果,不生效,并不能同步, 对于一个全局计数器累加,仍有脏数据。

@ethe
Copy link
Member

ethe commented Jul 8, 2019

这不属于 gunicorn_thrift 的本身的问题,所以抱歉我无法回答。

@victordudu1121
Copy link
Author

victordudu1121 commented Jul 9, 2019

@wooparadog @ethe 请问 这个PR 实现的gthread worker 我看就差Manual test了, 首先跟二位大神确认一哈, gthread worker使用起来支持 transport = tframedtransport么? 还是仍只支持tbufferdtrasport?
#61

我可以在我们实际的各个业务线线下测试场景应用gthread worker 进行实践测试

@wooparadog @ethe 最近在大规模应用gunicorn + thriftpy2 做性能优化,疑问较多,还望见谅!

@ethe
Copy link
Member

ethe commented Jul 9, 2019

看了一下源码,似乎没有不允许使用 TFramedTransport 的限制。我们在生产环境下使用的多进程 + Gevent + TBufferedTransport,可供参考。

@victordudu1121
Copy link
Author

看了一下源码,似乎没有不允许使用 TFramedTransport 的限制。我们在生产环境下使用的多进程 + Gevent + TBufferedTransport,可供参考。

@ethe @wooparadog 我们的某些业务场景必须使用Tframedtransport, 所以能否烦请 @wooparadog 帮确认,gthread worker 是否支持transport为Tframedtransport类型?
多谢, 多谢!

@victordudu1121
Copy link
Author

@ethe 你好! 我今天在使用gunicorn_thrift启动我的thriftpy2服务时, 想给app传递一些可变参数,我看gunicorn官方是支持package:build_app(a=1,b=2)这种方式去生成app的,如下:
https://stackoverflow.com/questions/8495367/using-additional-command-line-arguments-with-gunicorn

但是gunicorn_thrift看上去不支持这种方式生成app, 如下:
image

能否帮忙看看? 是否是使用方式错误
我的启动命令:
image

@junnplus
Copy link

junnplus commented Nov 15, 2019

@victordudu1121 gunicorn_thrift 应该是不支持工厂模式的调用方式,gunicorn 在 20.0 的版本也不兼容这种启动方式,详见:benoitc/gunicorn#2159
另外 @ethe 是否 load_obj 函数应该和 gunicorn 保持一致的行为,直接引用?https://github.com/benoitc/gunicorn/blob/master/gunicorn/util.py#L323

@ethe
Copy link
Member

ethe commented Dec 5, 2019

我没有找到 load_object 的部分。。上面那种工厂模式的方式 gunicorn 似乎也不支持,参数的部分应该可以有 walk around 的办法吧,比如环境变量什么的。

@wooparadog
Copy link
Member

嗯, 我们其实没有想完全追上上游的 feature 的. 工厂方法也有很多其他的方法实现. 就不在这个库里面加了.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants