JMS 连接数让我在 Netstat/MQ 资源管理器中感到困惑
JMS connection number confuse me in Netstat/MQ explorer
我在将 IBM MQ 与 Spring JMS 一起使用时遇到了一些问题。我正在使用 CachingConnectionFactory 来提高性能，但我注意到在 MQ 资源管理器应用程序连接 table 和 netstat 结果中 "strange"。
对于 CachingConnectionFactory.
，缓存会话大小配置为 5
- 在单个线程中创建一个或多个连接，我在 MQ 资源管理器和 netstat 中都看到 1 行。（好的，没问题）
- 创建一个连接，然后在单个线程中创建 5 个会话，我在 netstat 结果中看到 1 行，但在 MQ 资源管理器中看到 6 行。
- 现在我想在具有 5 个生产者线程的并发场景中进行测试，在每个线程中创建一个连接，我可以在 netstat 中看到 1 行，在 MQ 资源管理器中看到 1 行。
- 在与 3 相同的上下文中，创建一个连接，然后在每个线程中创建一个会话，我可以在 netstat 结果中看到 5 行，在 MQ 资源管理器中看到 (5 + 1) 行。如果在每个线程中执行 connection.close() => 行数不会改变。如果在每个线程中执行 session.close() => 行数不变。
被案例4搞糊涂了/.
我想在使用 MQConnectionFactory
时显示相同的分析结果
- 在单个线程中创建一个或多个连接，我在 MQ 资源管理器和 netstat 中都看到 1 行。（好的，没问题）
- 创建一个连接，然后在单个线程中创建 5 个会话，我在 netstat 结果中看到 1 行，但在 MQ 资源管理器中看到 6 行。
- 现在我想在有 5 个生产者线程的并发场景中进行测试，在每个线程中创建一个连接，我可以在 netstat 中看到 5 行，在 MQ 资源管理器中看到 5 行。
- 在与 3 相同的上下文中，创建一个连接，然后在每个线程中创建一个会话，我可以在 netstat 结果中看到 5 行，在 MQ 资源管理器中看到 10 行。如果在每个线程中执行 connection.close() => 两个线程中的行数现在都为 0。如果在每个线程中执行 session.close() => 行数在 netstat 中没有改变，但在 MQ IE 中减少到 5。
希望得到您的解释，谢谢
IBM MQ 级别详细信息
netstat 将向您显示到 MQ 队列管理器的侦听器端口的网络级 TCP 连接，这些连接将一对一地与通道实例数 运行ning.
匹配
IBM MQ v7.0 及更高版本支持每个 MQ 通道实例多路复用多个对话。 SVRCONN 频道上控制每个频道对话数量的设置是 SHARECNV，默认值为 10，这是根据服务器端和客户端设置协商的最小值，在 JMS 的情况下，通常这将匹配服务器端设置，除非使用 CCDT，在这种情况下它将根据 CLNTCONN 的 SHARECNV 值进行协商。
如果您运行在runmqsc中执行以下命令，您可以看到协商的SHARECNV值（MAXSHCNV）和当前对话数（CURSHCNV).
DIS CHS(CHL.NAME) CURSHCNV MAXSHCNV`
当您使用 runmqsc 中的以下命令或 MQ Explorer 中的应用程序连接 table 查看 MQ 中与 TCP 客户端相关的连接时，您将看到每个对话一个连接。
DIS CONN(*) TYPE(ALL)
JMS 详细信息
在 JMS 层，每个到队列管理器的连接都是一个对话。
在 JMS 层，每个会话都是另一个对话。
您可能会看到，如果您打开足够多的会话以超过 SHARCNV 限制并且另一个通道实例将启动，因此您将在 netstat 中看到另一个 "row"输出。
关于您的观察的注释：
您观察到：
Now I want to test in a concurrent scenario with 5 producer threads, create one connection in each thread, I can see 5 rows in netstat and 5 rows in MQ explorer.
In the same context as 3, create one connection and then create one session in each thread, I can see 5 rows in netstat result and 10 rows in MQ explorer. If doing connection.close() in each thread => rows count are now 0 in both of them. If doing session.close() in each thread => rows count are not changed in netstat, but decreased to 5 in MQ IE.
以下评论基于以下假设：SVRCONN 通道具有 SHARECNV(10)，并且您未使用具有 CLNTCONN 个通道且 SHARECNV 低于 10 的 CCDT .
已创建连接：根据我的阅读（您的观察结果同意），无论 SHARECNV 设置如何，每个连接都是一个新的通道实例。
为每个连接创建的会话：每个会话都将是与其关联的连接创建的同一通道实例中的一个附加对话。如果 SHARECNV(1)，您还将看到每个会话的新频道实例。
connection.close()：通过关闭 5 个连接，您关闭了在每个连接之上创建的会话，因此在资源管理器中看不到更多通道 运行ning 或连接是正常的。
session.close(): 这也是正常的，因为你关闭了5个会话然后你在资源管理器中观察到的5个连接将消失，但连接仍然会保持5个通道运行ning .
其他详细信息
另请注意，在 MQ v7.0 中添加了其他通道级改进，双向心跳就是其中之一。如果 MQ 客户端 v6.0 或更低版本连接到 MQ v7.0 或更高版本的队列管理器，则通道不会打开新功能（多路复用和双向 HB）。如果 MQ v7.0 或更高版本的客户端连接到 MQ v7.0 或更高版本的队列管理器，则可以通过设置 SHARECNV(0).
强制执行 v6.0 行为
设置SHARECNV(1)保留新频道功能但关闭多路复用。
如果 SHARECNV 设置为 0 或 1，则每个 JMS 连接和会话的通道数和 netstat "rows" 都会增加。
非默认性能增强设置
如果您使用的是 IBM MQ v8.0 或更高版本，IBM 建议使用 SHARECNV(1) 以获得 15% 的性能提升。您可以在这里阅读：IBM MQ 9.1.x Knowledge Center>Monitoring and performance>Tuning your IBM MQ network>Tuning client and server connection channels
The default settings for client and server connection channels changed in Version 7.0 to use shared conversations. Performance enhancements for distributed severs were then introduced in Version 8.0. To benefit from the new features that were introduced alongside shared conversations, without the performance impact on the distributed server, set SHARECNV to 1 on your Version 8.0 or later server connection channels.
From Version 7.0, each channel is defined by default to run up to 10 client conversations per channel instance. Before Version 7.0, each conversation was allocated to a different channel instance. The enhancements added in Version 7.0 also include the following features:
- Bi-directional heartbeats
- Administrator stop-quiesce
- Read-ahead
- Asynchronous-consume by client applications
For some configurations, using shared conversations brings significant benefits. However, for distributed servers, processing messages on channels that use the default configuration of 10 shared conversations is on average 15% slower than on channels that do not use shared conversations. On an MQI channel instance that is sharing conversations, all of the conversations on a socket are received by the same thread. If the conversations sharing a socket are all busy, the conversational threads contend with one another to use the receiving thread. The contention causes delays, and in this situation using a smaller number of shared conversations is better.
You use the SHARECNV parameter to specify the maximum number of conversations to be shared over a particular TCP/IP client channel instance. For details of all possible values, and of the new features added in Version 7.0, see MQI client: Default behavior of client-connection and server-connection. If you do not need shared conversations, there are two settings that give best performance in Version 8.0 or later:
- SHARECNV(1). Use this setting whenever possible. It eliminates contention to use the receiving thread, and your client applications can take advantage of the new features added in Version 7.0. For this setting, distributed server performance is significantly improved in Version 8.0 or later. The performance improvements apply to Version 8.0 or later client applications that issue non read ahead synchronous get wait calls; for example C client MQGET wait calls. When these client applications are connected, the distributed server uses less threads and less memory and the throughput is increased.
我在将 IBM MQ 与 Spring JMS 一起使用时遇到了一些问题。我正在使用 CachingConnectionFactory 来提高性能，但我注意到在 MQ 资源管理器应用程序连接 table 和 netstat 结果中 "strange"。
对于 CachingConnectionFactory.
，缓存会话大小配置为 5- 在单个线程中创建一个或多个连接，我在 MQ 资源管理器和 netstat 中都看到 1 行。（好的，没问题）
- 创建一个连接，然后在单个线程中创建 5 个会话，我在 netstat 结果中看到 1 行，但在 MQ 资源管理器中看到 6 行。
- 现在我想在具有 5 个生产者线程的并发场景中进行测试，在每个线程中创建一个连接，我可以在 netstat 中看到 1 行，在 MQ 资源管理器中看到 1 行。
- 在与 3 相同的上下文中，创建一个连接，然后在每个线程中创建一个会话，我可以在 netstat 结果中看到 5 行，在 MQ 资源管理器中看到 (5 + 1) 行。如果在每个线程中执行 connection.close() => 行数不会改变。如果在每个线程中执行 session.close() => 行数不变。
被案例4搞糊涂了/.
我想在使用 MQConnectionFactory
时显示相同的分析结果- 在单个线程中创建一个或多个连接，我在 MQ 资源管理器和 netstat 中都看到 1 行。（好的，没问题）
- 创建一个连接，然后在单个线程中创建 5 个会话，我在 netstat 结果中看到 1 行，但在 MQ 资源管理器中看到 6 行。
- 现在我想在有 5 个生产者线程的并发场景中进行测试，在每个线程中创建一个连接，我可以在 netstat 中看到 5 行，在 MQ 资源管理器中看到 5 行。
- 在与 3 相同的上下文中，创建一个连接，然后在每个线程中创建一个会话，我可以在 netstat 结果中看到 5 行，在 MQ 资源管理器中看到 10 行。如果在每个线程中执行 connection.close() => 两个线程中的行数现在都为 0。如果在每个线程中执行 session.close() => 行数在 netstat 中没有改变，但在 MQ IE 中减少到 5。
希望得到您的解释，谢谢
IBM MQ 级别详细信息
netstat 将向您显示到 MQ 队列管理器的侦听器端口的网络级 TCP 连接，这些连接将一对一地与通道实例数 运行ning.
IBM MQ v7.0 及更高版本支持每个 MQ 通道实例多路复用多个对话。 SVRCONN 频道上控制每个频道对话数量的设置是 SHARECNV，默认值为 10，这是根据服务器端和客户端设置协商的最小值，在 JMS 的情况下，通常这将匹配服务器端设置，除非使用 CCDT，在这种情况下它将根据 CLNTCONN 的 SHARECNV 值进行协商。
如果您运行在runmqsc中执行以下命令，您可以看到协商的SHARECNV值（MAXSHCNV）和当前对话数（CURSHCNV).
DIS CHS(CHL.NAME) CURSHCNV MAXSHCNV`
当您使用 runmqsc 中的以下命令或 MQ Explorer 中的应用程序连接 table 查看 MQ 中与 TCP 客户端相关的连接时，您将看到每个对话一个连接。
DIS CONN(*) TYPE(ALL)
JMS 详细信息
在 JMS 层，每个到队列管理器的连接都是一个对话。
在 JMS 层，每个会话都是另一个对话。
您可能会看到，如果您打开足够多的会话以超过 SHARCNV 限制并且另一个通道实例将启动，因此您将在 netstat 中看到另一个 "row"输出。
关于您的观察的注释：
您观察到：
Now I want to test in a concurrent scenario with 5 producer threads, create one connection in each thread, I can see 5 rows in netstat and 5 rows in MQ explorer.
In the same context as 3, create one connection and then create one session in each thread, I can see 5 rows in netstat result and 10 rows in MQ explorer. If doing connection.close() in each thread => rows count are now 0 in both of them. If doing session.close() in each thread => rows count are not changed in netstat, but decreased to 5 in MQ IE.
以下评论基于以下假设：SVRCONN 通道具有 SHARECNV(10)，并且您未使用具有 CLNTCONN 个通道且 SHARECNV 低于 10 的 CCDT .
已创建连接：根据我的阅读（您的观察结果同意），无论 SHARECNV 设置如何，每个连接都是一个新的通道实例。
为每个连接创建的会话：每个会话都将是与其关联的连接创建的同一通道实例中的一个附加对话。如果 SHARECNV(1)，您还将看到每个会话的新频道实例。
connection.close()：通过关闭 5 个连接，您关闭了在每个连接之上创建的会话，因此在资源管理器中看不到更多通道 运行ning 或连接是正常的。
session.close(): 这也是正常的，因为你关闭了5个会话然后你在资源管理器中观察到的5个连接将消失，但连接仍然会保持5个通道运行ning .
其他详细信息
另请注意，在 MQ v7.0 中添加了其他通道级改进，双向心跳就是其中之一。如果 MQ 客户端 v6.0 或更低版本连接到 MQ v7.0 或更高版本的队列管理器，则通道不会打开新功能（多路复用和双向 HB）。如果 MQ v7.0 或更高版本的客户端连接到 MQ v7.0 或更高版本的队列管理器，则可以通过设置 SHARECNV(0).
设置SHARECNV(1)保留新频道功能但关闭多路复用。
如果 SHARECNV 设置为 0 或 1，则每个 JMS 连接和会话的通道数和 netstat "rows" 都会增加。
非默认性能增强设置
如果您使用的是 IBM MQ v8.0 或更高版本，IBM 建议使用 SHARECNV(1) 以获得 15% 的性能提升。您可以在这里阅读：IBM MQ 9.1.x Knowledge Center>Monitoring and performance>Tuning your IBM MQ network>Tuning client and server connection channels
The default settings for client and server connection channels changed in Version 7.0 to use shared conversations. Performance enhancements for distributed severs were then introduced in Version 8.0. To benefit from the new features that were introduced alongside shared conversations, without the performance impact on the distributed server, set SHARECNV to 1 on your Version 8.0 or later server connection channels.
From Version 7.0, each channel is defined by default to run up to 10 client conversations per channel instance. Before Version 7.0, each conversation was allocated to a different channel instance. The enhancements added in Version 7.0 also include the following features:
- Bi-directional heartbeats
- Administrator stop-quiesce
- Read-ahead
- Asynchronous-consume by client applications
For some configurations, using shared conversations brings significant benefits. However, for distributed servers, processing messages on channels that use the default configuration of 10 shared conversations is on average 15% slower than on channels that do not use shared conversations. On an MQI channel instance that is sharing conversations, all of the conversations on a socket are received by the same thread. If the conversations sharing a socket are all busy, the conversational threads contend with one another to use the receiving thread. The contention causes delays, and in this situation using a smaller number of shared conversations is better.
You use the SHARECNV parameter to specify the maximum number of conversations to be shared over a particular TCP/IP client channel instance. For details of all possible values, and of the new features added in Version 7.0, see MQI client: Default behavior of client-connection and server-connection. If you do not need shared conversations, there are two settings that give best performance in Version 8.0 or later:
- SHARECNV(1). Use this setting whenever possible. It eliminates contention to use the receiving thread, and your client applications can take advantage of the new features added in Version 7.0. For this setting, distributed server performance is significantly improved in Version 8.0 or later. The performance improvements apply to Version 8.0 or later client applications that issue non read ahead synchronous get wait calls; for example C client MQGET wait calls. When these client applications are connected, the distributed server uses less threads and less memory and the throughput is increased.