我有一个应用程序,其中消息以每小时70K
XML的速率传输.我们使用这些
XML消息并将其存储到中间队列中.创建中间队列是因为我们需要满足24小时消耗所有消息的SLA.我们可以在24小时内使用XMLS并将其加载到内部队列中.在将其加载到内部队列之后,我们处理XMLS(解析,应用非常少的转换,执行非常少的验证)并将数据存储到高度规范化的数据模型中.我知道数据模型会对性能产生巨大影响,遗憾的是,我们无法控制数据模型.目前,我们需要3.5分钟来处理2K消息,这是不可接受的.对于2K消息,我们希望将其降低到1分钟.以下是我们迄今为止所做的工作：
1)适用时应用索引.
2)使用XMLBeans来解析XML(每个XML的大小不是很大)
3)删除所有不必要的验证,transformatios等.
该应用程序运行于：
操作系统：RHEL 5.4 64位
平台：JDK 1.6.0_17,64位
数据库：Oracle 11g R2 64位(2节点集群)
外部MQ：IBM Queue
内部临时存储MQ：JBoss MQ
应用服务器：Jboss 5.1.0.GA(EAP版)
我们使用和处理XML消息的顺序非常重要,因此我们无法进行并行处理.
我们还能做些什么来提高性能吗？
解决方法
即使在小型服务器上,WebSphere MQ也可以比您描述的速率更快地卸载消息.
Windows Performance Report for WMQ V7在客户端频道上每秒超过2,200次2k持续往返(一次请求和一次回复)测试.那是每秒超过4,000条消息.
您的案例中的瓶颈似乎是处理消息的延迟以及以特定顺序处理消息的依赖性.可以为您提供最佳性能提升的选项是消除顺序依赖性.当我在银行工作时,我们有一个系统按照他们到达的确切顺序发布交易,每个人都说这个要求是强制性的.但是,我们最终修改了系统,以便在白天执行备忘录,然后在稍后的步骤中重新发布.备忘录发布以任何顺序发生,并支持并行性,故障转移和多实例处理的所有其他好处.最后的帖子在逻辑顺序中(并且实际上以对客户最有利的顺序)应用了交易,一旦它们都在数据库中.序列依赖关系将您锁定为单例模型,并且是异步消息传递的最坏情况要求.尽可能消除它们.
另一个需要改进的方面是解析和处理消息.只要您遇到顺序依赖,这是提高性能的最佳选择.
最后,您总是可以选择以更多内存,cpu,更快的磁盘I / O等形式来解决问题.从本质上讲,这是针对具有强大功能的软件架构,并且永远不是最佳解决方案,但通常会为您提供足够的时间来解决根本原因.
