java - EMS性能问题

标签 java concurrency jms tibco-ems ems

我正在编写一个服务无状态传入请求的服务。这些请求都是数学计算,执行时​​间不会很长(最多2ms)。

我使用 Tibco EMS 在客户端/服务器之间进行通信。提供了一个客户端库,它包装了客户端逻辑(例如,将数据转换为 EMS 消息等)并将请求发送到请求队列。服务器端处理请求并将响应发送到单独的队列中。这工作得很好。

服务器端是多线程的。当收到新的传入请求时,将创建一个新线程。因此,请求是同时处理的。

服务器端使用与 EMS 服务器的单个 EMS 连接。但是,由于 EMS Session 不是线程安全的,如果我希望能够在每个线程中将响应写入 EMS 队列,我必须使用 connectionFactory 为每个线程创建一个 session 。这降低了性能。

流量花费的时间约为3-4ms,即发送请求和收到响应之间的时间约为5-6ms。(3-4ms用于传输、编码/解码,2ms用于计算)

是否有任何解决方案允许我同时发送到 EMS 队列而无需创建两个过多的 JMS 对象?

为了进一步优化服务,我还需要遵循其他重要规则吗?已经遵循了一些基本的优化准则:

  1. 使用CachedConnectionPool
  2. 以 NON_PERSISTANT 形式发送 JMS 消息
  3. 使用一个 EMS 连接来处理所有请求。

非常感谢。

最佳答案

您遇到的行为并非 EMS 特有。该行为由 JMS 规范本身规定。以下是 JMS 规范第 2.8 节的摘录:

There are two reasons for restricting concurrent access to Sessions. First, Sessions are the JMS entity that supports transactions. It is very difficult to implement transactions that are multithreaded. Second, Sessions support asynchronous message consumption. It is important that JMS not require that client code used for asynchronous message consumption be capable of handling multiple, concurrent messages. In addition, if a Session has been set up with multiple, asynchronous consumers, it is important that the client is not forced to handle the case where these separate consumers are concurrently executing. These restrictions make JMS easier to use for typical clients. More sophisticated clients can get the concurrency they desire by using multiple sessions.

如果您想避免创建(和销毁)那么多对象,您可能需要预先创建一个线程池,并预先为每个线程分配一个 session 。

关于java - EMS性能问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/28223921/

相关文章:

c++ - 并发读写的嵌入式数据库

java - 来自 Callable 的 CompletableFuture?

java - 安排消息驱动 bean 在特定时间访问队列?

java - CXF : No method was found for the WSDL operation

java - 编译器 "know"是否在强制转换之前了解变量的类型?

language-agnostic - 您如何处理/响应 GUI 层上的用户输入并发性?

java - WildFly Swarm 配置 Messaging Remote

maven-2 - Glassfish 应用程序无法与 Maven 库(gf-client)一起使用

java - 我可以使用拦截器检查 JAX-RS 应用程序中的 http header 吗?

java - 函数式接口(interface) + 数组中整数总和的 lambda 表达式