Are there any plans to support TThreadPoolServer or TNonblockingServer?

[victordudu1121]

请问 有计划支持 TThreadPoolServer 和 TNonblockingServer 么？ 我们有较强需求！

谢谢
braver

[ethe]

Thriftpy2 has already supported asyncio on 3.x and Tornado on 2.x. I think there is no need to support other nonblocking service implementations.

[ethe]

But we do not refuse to accept it, if you have plans to realize them, I am glad to merge those pull requests in the future.

[victordudu1121]

So, I see. Thank you for your prompt reply.
Follow-up questions to consult again!

[wooparadog]

Actually, I've got some free time now and I'll take a look into it. Some help testing thread worker is extremely welcome. Thriftpy/gunicorn_thrift#61

[victordudu1121]

Thriftpy2 has already supported asyncio on 3.x and Tornado on 2.x. I think there is no need to support other nonblocking service implementations.

@ethe
We now use the TthreadServer of thriftpy2 on the server side, that is, the multi-threaded server. The number of concurrent clients on the client side exceeds 200, and the serer end starts to lose packets. Therefore, I want to use the tornado server in the production environment. The processing power of the server will not be greatly improved. Upgrade? Without thriftpy2, use apache thrift TNobBlockingServer directly, the server can handle concurrent requests 500

I am very grateful for your practical experience and reply, which is very helpful for us to improve the server's interactive throughput performance.

[ethe]

If you do not use gunicorn_thrift to proxy your thrift service in production environment, you should use it to start and manage multiple workers. ThriftPy aims to provide a minimal thrift service realization, if you need some advanced feature (like concurrent ability), you should use other tools (like Gunicorn) or package it by yourself. There are some suggestions to make your server handle more concurrent requests:

1. Use Gunicorn as a proxy service (with gunicorn_thrift)
2. Nonblocking service
   1. Gevent (monkey patch needs nothing special supports)
   2. Asyncio (on Python 3.4 or later, Thriftpy2 has already supported it)
   3. Tornado (yet another nonblocking server plan on Python 2, Thriftpy has already supported it)

[victordudu1121]

If you do not use gunicorn_thrift to proxy your thrift service in production environment, you should use it to start and manage multiple workers. ThriftPy aims to provide a minimal thrift service realization, if you need some advanced feature (like concurrent ability), you should use other tools (like Gunicorn) or package it by yourself. There are some suggestions to make your server handle more concurrent requests:

1. Use Gunicorn as a proxy service (with gunicorn_thrift)

2. Nonblocking service

   1. Gevent (monkey patch needs nothing special supports)
   2. Asyncio (on Python 3.4 or later, Thriftpy2 has already supported it)
   3. Tornado (yet another nonblocking server plan on Python 2, Thriftpy has already supported it)

@ethe
For the current minimum cost of change, I tend to choose tornado, but according to your reply (3. Tornado (other non-blocking server program in Python 2, Thriftpy already supports it)), meaning that thriftpy2 has implemented another TNonBlockingServer, Replace Tornado, but you are referring to the tornado server now implemented in threaty2?

[ethe]

🤣 我的意思是 tornado （又）是一个 python 2.x 下非阻塞服务的非官方实现。你的英文还待加油啊兄弟。。

[victordudu1121]

🤣 我的意思是 tornado （又）是一个 python 2.x 下非阻塞服务的非官方实现。你的英文还待加油啊兄弟。。

@ethe
明白了！ 多谢 多谢！ 我的server还依赖了一些公司的库， 不好迁移python3.4+, 所以短期半年内，只能跑在python2.7上！ 用tornado实现异步非阻塞server，相比TThreadServer, server端的吞吐会提升很多么？ 我的server端主要消耗在消息序列化和rpc调用第三方上。

[microdog]

@victordudu1121 如果你认为序列化是瓶颈，可以尝试水平拓展以及 PyPy 。如果存在大量并发，可以先考虑尝试一下 gevent 。你整套迁移到 Tornado 的成本还是相当高的。

[victordudu1121]

@victordudu1121 如果你认为序列化是瓶颈，可以尝试水平拓展以及 PyPy 。如果存在大量并发，可以先考虑尝试一下 gevent 。你整套迁移到 Tornado 的成本还是相当高的。

@microdog 您好！ 我看tornado thriftpy2官方给的示例如下：
Thriftpy/thriftpy#305
相比我原来用的thriftpy2 的TThreadServer, 应用层面， 我需要做的升级并不大啊？ 还请指教，迁移Tornado, 主要成本在和风险在哪？
感谢你的热心回复和帮助！

[microdog]

@victordudu1121 使用 Tornado 的话，你在应用层面就不能进行长时间阻塞操作，几乎所有涉及到 IO 的操作都需要调整，比如你提到的 RPC 调用，需要你将 RPC 调用重构为与 Tornado 异步兼容的实现，或使用线程池去执行。而 gevent 的话，几乎可以无痛迁移。

Tornado 包含执行 HTTP 请求的例子可以看这个 PR 中的 Demo：Thriftpy/thriftpy#206