One thread can be receiving data down the wire, while another thread is waiting in commit. Having multiple threads from an application means the network can be better utilized. You get overlapped writing to the log, the units of work are shorter in duration, you can get parallel IO. Having parallel threads gives you better throughput than one thread.Keep queue data in memory – ( buffer pools on z/OS, queue buffer on midrange), so few messages on the queue.The rate at which MQ can write its logs.There are papers written on this but here is a one minute overview As fast as the queue manager can process data How many messages I can consume : Max number of messages can be processed? or throttle limit One customer found one thread was optimum because there was no database delays.Using more threads should improve throughput, unless this is delayed by external factors – such as database locks.This may be important to your business transaction if you have to worry about response time. This means that the data in the database (or replies etc) are visible earlier. Rather than have one thread process 1000 messages per commit (taking 1010 ms) you may want to have multiple threads processing 10 messages per commit – taking 20 ms. You need to understand the database and find the optimum number of requests per commit for your business transaction. So overall MQ throughput goes up – but the business transaction suffers. These locks may prevent other applications from accessing data, either the recently inserted records, page locks, or index locks. The down side is that the database requests will keep locks until the commit. If the application logic is a get followed by a database insert, followed by a commit, then doing 50 gets, 50 inserts and a commit, will work much faster. This is clearly a great improvement, but possibly selfish. For 10KB messages, this may be 1000 messages per commit. For a 100MB message it is one message per commit. This depends on the message size, logging rates and other factors. There is a “sweet spot” of messages per commit to give you maximum data processed per second. This is how channels can send messages efficiently. If you did 50 gets – taking 50 ms and a commit taking 10 ms, this is 50 messages in 50 + 10 ms which equates to one message every 1.2 milliseconds almost 10 times faster. This is one message processed every 11 ms. Consider a get taking 1 millisecond, and a commit taking 10 ms.
Take the worst case of using persistent messages, which require log IO during commit.įor one thread, processing multiple messages before doing a commit means the thread can do more work. How many messages I can consume: Concurrently: A file system with the speed of writing an illuminated letter to parchment.This could be due to database locking, or a badly designed statement, for example a query which needs to access thousands or millions of rows. There is clearly something else going on. Processing one messages and commit should take about 10 milliseconds or less( say 30 ms for a two phase commit). Current system take around 500ms for processing of 1 message after it read from queue and till it commit. Max number of messages can be processed? or throttle limitĪ good meaty performance question I thought.I want to know how many messages I can consume I have a standalone multi threaded java application which listen messages from IBM MQ.Ĭurrent system take around 500ms for processing of 1 message after it read from queue and till it commit. There was a question on the MQ section on StackOverflow
0 kommentar(er)
