Author |
Message
|
harsha8127 |
Posted: Mon Jun 08, 2015 9:07 pm Post subject: Queue Depth Calculating. |
|
|
Acolyte
Joined: 25 Nov 2013 Posts: 72
|
Hi Docs,
Iam a MQ ADMIN,
I got a query from my Client, need your help.
The query is "How to fix" (not how you give) the Queue Depth for perticular queue. Based on what we should calculate or fix the queue depth.
eg: there is big finance company where there are somany of users and for every 1min 100 users do transaction. Now by default the queue depth is 5000
and depending upon the situation how should we calculate or how much shuld we keep the queue depth.
 |
|
Back to top |
|
 |
zpat |
Posted: Tue Jun 09, 2015 12:29 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
The default max depth of 5,000 is pretty out of date, I've made ours 50,000 (and also I make ours persistent by default).
Make the depth whatever you think you might need. It does not reserve any disk space in advance. _________________ 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 |
|
 |
exerk |
Posted: Tue Jun 09, 2015 1:36 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
harsha8127 wrote: |
...Based on what we should calculate or fix the queue depth... |
1. The application profile, i.e. can it dequeue messages at the same rate (or better) than they enqueue?
2. Peak volumes, i.e. there will be times when the enqueue of messages is periodically greater than the dequeue;
3. How long it is required to 'stack' messages due to an application outage.
There are also other considerations but the above are just starting points. Alternatively, you could just set very large queue depths.
zpat wrote: |
...and also I make ours persistent by default... |
All well and good provided the applications that put the original message honour the setting. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
zpat |
Posted: Tue Jun 09, 2015 1:53 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
exerk wrote: |
All well and good provided the applications that put the original message honour the setting. |
"Persistence as per queue default", is the default MQI option, which for once is a helpful default.
Can't totally prevent stupid coding of course, but it helps avoid accidents. _________________ 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: Tue Jun 09, 2015 4:37 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
zpat wrote: |
The default max depth of 5,000 is pretty out of date, ... |
IBM packages MQ and other products with initial values (defaults?) adequate for installation verification testing and proof-of-concept, but not production. _________________ 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 |
|
 |
fjb_saper |
Posted: Tue Jun 09, 2015 4:42 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
And of course you have to give consideration on whether or not you need large file support (> 2 GB).  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Vitor |
Posted: Tue Jun 09, 2015 4:49 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
exerk wrote: |
Alternatively, you could just set very large queue depths. |
This is not a bad strategy.
However, one of the reasons queues have a maximum depth parameter (rather than just adding messages until they run out of space) is to prevent an application stuck in a loop adding the same message over and over. A very effective way of ending such a loop is for the put to fail with a 2053 error which trips the application error handling.
Whatever you decide to use for max depth, be sure you have enough disc to cover the queue reaching this maximum, even if the maximum is a theoretical and unlikely situation. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Jun 09, 2015 6:10 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
And with enough Disk Vitor means Queue space + LOG Space ...
Remember if those messages are persistent they will hit the log too  _________________ MQ & Broker admin |
|
Back to top |
|
 |
zpat |
Posted: Tue Jun 09, 2015 6:43 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
bruce2359 wrote: |
zpat wrote: |
The default max depth of 5,000 is pretty out of date, ... |
IBM packages MQ and other products with initial values (defaults?) adequate for installation verification testing and proof-of-concept, but not production. |
Yes and Universities generate so-called "IT professionals" who have no idea about these matters and do not get proper training and come here for help.
It's not a good thing and it needs changing. The IBM defaults are out of date. People do use defaults when they know no better. Fact of life. _________________ 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 |
|
 |
exerk |
Posted: Tue Jun 09, 2015 9:09 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
zpat wrote: |
...The IBM defaults are out of date... |
So what would be a good default? 50,000? 500,000? 999,999,999? Someone, at some time, had to make a value decision for an initial value, and I'm pretty sure that if the default was all the nines the discussion would be inverse, i.e. why does the vendor set such a ridiculously high default? Surely if 5000 is too low then site standard will have a hardening/alteration script that will set the model and other queues to what is considered more 'in date'. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Jun 09, 2015 9:11 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
zpat wrote: |
People do use defaults when they know no better. Fact of life. |
And they learn when they get burned the first time.
And their company learns that less trained employees means more outages.
And then the company does nothing about it...  |
|
Back to top |
|
 |
Vitor |
Posted: Tue Jun 09, 2015 9:33 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
mqjeff wrote: |
zpat wrote: |
People do use defaults when they know no better. Fact of life. |
And they learn when they get burned the first time.
And their company learns that less trained employees means more outages.
And then the company does nothing about it...  |
And then the company calculates the cost of the outage * probability of future outages against increased cost of better staff * certainty of having to pay people and does nothing about it.
So because it's a decision based on crass, stupidly short sighted thinking it's perfectly justifiable. It's not like that just can't be bothered.....
....oh wait..... _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
gbaddeley |
Posted: Tue Jun 09, 2015 6:58 pm Post subject: |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
General guidance for maxdepth is the highest curdepth that would be experienced during the longest likely extended outage on the consuming app, plus an extra allowance. This might be 1 hour, 1 day or 1 week. Think about DR scenarios. If the messages are large or high volume or persistent, the queue disk space and recovery log disk space will also need to be considered.
maxdepth is a hard limit. Messaging failures will occur if the queue fills. Its best to avoid this happening in production by setting a large value. _________________ Glenn |
|
Back to top |
|
 |
harsha8127 |
Posted: Tue Jun 09, 2015 8:46 pm Post subject: |
|
|
Acolyte
Joined: 25 Nov 2013 Posts: 72
|
zpat wrote: |
The default max depth of 5,000 is pretty out of date, I've made ours 50,000 (and also I make ours persistent by default).
|
What is "Out of date".Even for Verssion 9 after creation of queue the default is 5000 and it is not changed. That is why it is called "DEFAULT"
zpat wrote: |
Make the depth whatever you think you might need. It does not reserve any disk space in advance. |
What ever I think means? Should i not consider the current flow and the requirment. If i think and keep 20000 depth and if the flow is more than that ...???
or if i keep 100000 depth and if it is too more or the origially required is 20000 there will be load on the qmgr and the server...??
That is why i have posted if there is any calculation or any way of thinking.
 |
|
Back to top |
|
 |
harsha8127 |
Posted: Tue Jun 09, 2015 8:50 pm Post subject: |
|
|
Acolyte
Joined: 25 Nov 2013 Posts: 72
|
fjb_saper wrote: |
And of course you have to give consideration on whether or not you need large file support (> 2 GB).  |
Does the Queue depth depends on the message size or length..  |
|
Back to top |
|
 |
|