web stats
Mirth Community - View Single Post - Database Reader Thread Count
View Single Post
Old 04-20-2017, 03:12 PM
narupley's Avatar
narupley narupley is online now
Mirth Employee
Join Date: Oct 2010
Posts: 7,116
narupley is on a distinguished road

Originally Posted by collinsmj View Post
1.In dashboard view my destination queue is always reporting it is at 9. Source will be 0 to 3. How does that work? I have expected the source to be setting at my queue buffer size or have destination threads queue instead of each thread having 1 message waiting.
That probably just means your destination queue is never growing beyond 9 or 10. If your queued count is staying more or less static, it means that the rate at which messages are being added to the destination queue is about the same as the rate at which messages are being dispatched outbound. Since your max processing threads is set to 1, the source queue thread will process one message at a time through your channel, up until the point at which it drops it into the destination queue. The transformer logic you have in your channel likely factors into this. To increase throughput, you can increase your Max Processing Threads so that multiple consumer threads will simultaneously poll and process messages through your channel (and therefore, messages will be added to the destination queue more rapidly). That is of course assuming that the source of messages (source connector or originating client system) is sending you messages quickly enough for it to make a difference.

Originally Posted by collinsmj View Post
2. How does increasing the MAX Processing Threads on the source queue assist with overall channel through put. Please see this mirth connect thread from last year. I have toyed with this setting but see no difference.
When the source queue is enabled, multiple processing threads essentially means multiple source queue threads, all consuming from the same source queue simultaneously. If you increase this value and see no difference in throughput, it could mean that the source connector or originating system isn't adding messages to the source queue quickly enough for it to make a difference. For a Database Reader source connector, it could mean that the database server itself is just not fast enough, or there is some connection latency bottleneck. Or, you may be running into a bottleneck with the I/O write speeds on the underlying storage system you're using for the Mirth Connect database. As with most high volume applications, these things work best when you're using fast SSD storage, not spinning disks.

Originally Posted by collinsmj View Post
3.How does having multiple destination queues help with throughput? I only have 1 destination over the network. I only ever see one message being processed in the dashboard messages view. I do not see 3 or 4 messages processing at a destination the same time.
If you have multiple destination queue threads, then again they will all consume from the same destination queue simultaneously. When you search by the QUEUED status in the message browser, are you saying you only ever see one message? It could be because the rate at which messages are being added to the destination queue is slower than the rate the destination queue is dispatching messages outbound.

Overall, it sounds like you're running into a performance bottleneck somewhere else, not related to the channel configuration per se. Try proving it one way or another by blasting multiple messages simultaneously at the channel. You can use a separate JavaScript Reader channel with a polling interval of something low like 100 ms, and 10 processing threads. I'll attach a channel to show what I mean. When blasting messages, try it when your main channel is using 1 processing thread, and then try it again when your main channel is using 10 processing threads.
Attached Files
File Type: xml Example - Blast Messages.xml (10.3 KB, 21 views)
Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

Nicholas Rupley
Work: 949-237-6069
Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.

- How do I foo?
- You just bar.

Last edited by narupley; 04-20-2017 at 03:14 PM.
Reply With Quote