我有一个应用程序，其中消息以每小时70K XML的速度不断增长。我们使用这些XML消息并将其存储到中间队列中。之所以创建中间队列，是因为我们需要满足24小时使用所有消息的SLA。我们能够在24小时内使用XMLS并将其加载到内部队列中。将其加载到内部队列之后，我们处理XMLS(解析，执行很少的转换，执行很少的验证)并将数据存储到高度规范化的数据模型中。我知道数据模型会对性能产生巨大影响，不幸的是，我们无法控制该数据模型。目前，我们需要3.5分钟来处理2K消息，这是 Not Acceptable 。我们希望将其减少到1分钟以处理2K条消息。到目前为止，这是我们所做的:
1)适用的适用索引。
2)使用XMLBeans解析XML(每个XML的大小不是很大)
3)删除了所有不必要的验证，转换等。
该应用程序在以下位置运行:
操作系统:RHEL 5.4 64位
平台:JDK 1.6.0_17，64位
数据库:Oracle 11g R2 64位(2节点群集)
外部MQ:IBM队列
内部临时存储MQ:JBoss MQ
应用程序服务器:Jboss 5.1.0.GA(EAP版本)
我们使用和处理XML消息的顺序非常重要，因此我们无法进行并行处理。
我们还可以采取其他措施来提高绩效吗？
最佳答案
即使在小型服务器上，WebSphere MQ可以比您描述的速度更快地卸载消息。 Windows Performance Report for WMQ V7在客户端 channel 上每秒进行了超过2200次2k持久往返(一次请求和一次回复)测试。每秒超过4,000条消息。
在您的情况下，瓶颈似乎是处理消息的延迟以及对按特定顺序处理消息的依赖性。可以使您提高MOST性能的选项是消除订单依赖性。当我在银行工作时，我们有一个系统，该系统按照交易到达的确切顺序进行过帐，每个人都说此要求是强制性的。但是，我们最终对系统进行了修改，使其在白天执行了便笺发布，然后在后续步骤中重新发布。备忘录发布以任何顺序发生，并支持并行性，故障转移和多实例处理的所有其他优点。一旦所有事务都进入数据库，最后的帖子将按照逻辑顺序(实际上是对客户最有利的顺序)应用事务。序列相关性将您锁定为单例模型，这是异步消息传递的最坏情况要求。尽可能消除它们。
另一个需要改进的方面是消息的解析和处理。只要您对序列依赖性有所了解，这就是提高性能的最佳选择。
最后，您始终可以选择以更多的内存，CPU，更快的磁盘I/O等形式来解决问题。从本质上讲，这是在以强大的能力来解决软件体系结构，它永远不是最好的解决方案，但通常它会为您提供足够的时间来解决根本原因。
关于xml - 如何提高基于MQ的批处理应用程序的性能？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/6228128/