| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Improve messaging throughput on IBM MQ at mqseries.net? Tips |
« View previous topic :: View next topic » |
| Author |
Message
|
| jasonn |
 Posted: Fri Aug 18, 2023 10:12 pm Post subject: Improve messaging throughput on IBM MQ at mqseries.net? Tips |
 |
|
Newbie
Joined: 22 Dec 2022
Posts: 6
|
Hello, I'm currently experiencing performance issues with IBM MQ on mqseries.net. Specifically, I'm encountering slow messaging throughput. Messages take longer than expected to be processed, and it's impacting the overall efficiency of our system.
I wanted to inquire if there are any recommended best practices or optimizations that can help improve the messaging throughput. Are there specific configuration settings, tuning techniques, or considerations that we should be aware of?
We have already reviewed our hardware resources and ensured they meet the recommended specifications. We are also using the latest version of IBM MQ.
Any guidance or suggestions you can provide to enhance the messaging throughput and address the performance issues would be greatly appreciated. Thank you for your assistance in resolving this matter.
Last edited by jasonn on Sun Aug 20, 2023 10:38 pm; edited 1 time in total |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Aug 18, 2023 11:33 pm Post subject: Re: Improve messaging throughput on IBM MQ at mqseries.net? |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| jasonn wrote: |
Hello, I'm currently experiencing performance issues with IBM MQ on mqseries.net. Specifically, I'm encountering slow messaging throughput. Messages take longer than expected to be processed, and it's impacting the overall efficiency of our system.
I wanted to inquire if there are any recommended best practices or optimizations that can help improve the messaging throughput. Are there specific configuration settings, tuning techniques, or considerations that we should be aware of?
We have already reviewed our hardware resources and ensured they meet the recommended specifications. We are also using the latest version of IBM MQ.
Any guidance or suggestions you can provide to enhance the messaging throughput and address the performance issues would be greatly appreciated. Thank you for your assistance in resolving this matter. |
You are not giving us much to go with. Performance considerations are always very vague without specification of message rate and message size, whether the messages are marked as persistent or not..., the kind of hardware you are throwing at it, etc...
What seems slow to one person might be blazing fast to the other.
And don't forget the network. A misconfigured router or bad network card can also greatly affect throughput....
Hope it helps 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Sat Aug 19, 2023 1:58 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
If messages are persistent (and assuming they need to be) then i/o performance will usually be the limiting factor.
Use as much memory caching (fast write) as possible.
The default MQ triple-write mode for logs seems a bit dated with modern SAN storage - I always used single-write and never had any issues.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Aug 19, 2023 10:44 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
Performance tuning is quite complicated, and requires more precise analysis. "Running slowly" is not precise.
Performance improvement generally falls into three broad categories: tune, if you haven't already done so, steal needed resources from lesser importance workloads, buy more resources.
If you have spinning disks, replace them with SSD's.
If your o/s is paging/swapping, get more RAM.
A few questions for you:
- is everything in the o/s image (LPAR) running slow?
- is just this one qmgr running slow?
- is just one application running slow?
- is a data base involved?
- when did you notice slow response begin? What happened just prior to that?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Andyh |
| Posted: Sun Aug 20, 2023 9:30 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 237
|
I fully agree that there is insufficient information here to offer good advice.
ZPAT states "The default MQ triple-write mode for logs seems a bit dated with modern SAN storage - I always used single-write and never had any issues."
In order for SingleWrite to be safe then the atomicity of 4K aligned 4KB synchronous writes must be guaranteed. That is, when one 4KB page on a 4K aligned offset is overwritten with new content then the end result must be either the initial content, or the final content, but NEVER some intermediate state regardless of what failure might occur during the write.
Getting this level of guarantee throughout the entire IO stack is surprisingly difficult.
The implications of NOT using SingleWrite tend to only be significant when there is insufficient concurrency in the workload. For example a simplistic workload where a single app puts and gets persistent messages will typically show a big improvement through the use of SingleWrite, but 100's of apps all concurrently putting and getting messages (inside syncpoint) would typically see much smaller gains.
IF IN ANY DOUBT THEN YOU SHOULD USE THE DEFAULT TripleWrite setting. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Aug 20, 2023 12:30 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
I continue:
Performance tuning is an advanced task. I'd recommend taking an introductory IBM MQ System Administration course - with hands-on lab exercises - for example https://www.ibm.com/training/course/ibm-mq-v9-system-administration-using-linux-for-labs-WM154G
There are always bottlenecks. Look for low-hanging fruit opportunities first, those which promise to improve throughput with low/lesser risk. I usually recommend clients upgrade hardware before other tuning efforts.
For example, replacing spinning disks with SSDs, if disk access is the bottleneck. If network is a bottleneck, replacing copper cabled NIC cards with fiberoptic. Add more processors if procesor access is your bottleneck. Add more RAM if paging/swapping is your bottleneck.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Last edited by bruce2359 on Mon Aug 21, 2023 7:06 am; edited 1 time in total |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Aug 20, 2023 3:37 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2495
Location: Melbourne, Australia
|
| Quote: |
| Hello, I'm currently experiencing performance issues with IBM MQ on mqseries.net. Specifically, I'm encountering slow messaging throughput. Messages take longer than expected to be processed, and it's impacting the overall efficiency of our system. |
That's a strange expression "on mqseries.net".
I suggest that you take an end-to-end view, and closely look at every link in the chain. In 99% of poor performance cases, MQ is running fine, and something else is the bottleneck. The challenge is to find that "something else".
MQ is highly optimised for performance out-of-the-box, so unless the app is making bad use of MQ, there is generally not a lot that can be done in MQ to greatly boost performance.
Can you reproduce the performance issue in a non-production environment?
_________________
Glenn |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
