Should I pool sessions or connections?

[relu91]

Hello, community!

I'm developing a TypeScript client for IoTDB on top of the Thrift autogenerated source, and I'm considering how to manage sessions and connections for optimal performance and resource management.

From what I've observed, the reference implementations in Java and Python appear to pool sessions rather than connections (AFIK). However, I'd love to get more insights from those with experience or knowledge of IoTDB's architecture. Specifically:

• What exactly is a "session" in IoTDB? Should it be treated as something that lives for a single request, or could/should it be long-lived, potentially spanning multiple requests in a microservice?

• Best Practices for Pooling: Should I pool sessions, as in the Java and Python clients, or is there any benefit to pooling at the connection level instead? I'd like to understand if one approach is better than the other for common IoTDB use cases.

Any guidance would be greatly appreciated!

Thanks in advance for your insights.

[CritasWang]

hi, relu91

You are so cool.

The session is a client used to establish connections and provide operations. The internal connections within the session should be long-lived to avoid duplicate establishment of TCP channels. A session can only make one RPC request at a time.

Therefore, pooling sessions will be quite important, as they can provide more requests with fewer connections and save resources to a greater extent.

Regarding the granularity of pooling, it should be at the session level because there is a cluster behind it, so each session may connect to different nodes (holding different connections), and IoTDB has an internal redirection mechanism that recommends redirecting the corresponding session to a certain node. This is quite important in certain scenarios.

In addition, during query operations, connections may be occupied for a long time. Of course, pooling connections also have their advantages, as they may control resources at the socket level. Just maintenance may be more complicated. If you have the energy, perhaps you can compare the two options.