| Author |
Message
|
| zpat |
 Posted: Wed Jul 31, 2013 7:13 am Post subject: |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
| mqjeff wrote: |
Please don't confuse my technical accuracy for an attack on your solution.
 |
Ever hear the story about the lost helicopter pilot and the IBM'er?
Last edited by zpat on Wed Jul 31, 2013 7:28 am; edited 1 time in total |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Jul 31, 2013 7:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
| mqjeff wrote: |
Please don't confuse my technical accuracy for an attack on your solution.
|
Ever hear the story about the lost helicoper pilot and the IBM'er? |
I'm sure I did, but it was a dog and a horse that walked into a bar. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 31, 2013 7:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| Really don't see your problem here. It's much better in nearly all respects to MQ clustering for the purpose of allowing multiple application servers to process a shared workload. |
Ok, I'll bite. How does this deal with the scenario I outline above, where the number of connections you need to process within SLA is more than the single queue manager can handle and/or the persistent message traffic causes sufficient latency in the single queue manager that the multiple outstanding get requests which are queued cause you to miss SLA?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 31, 2013 7:26 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| mqjeff wrote: |
Please don't confuse my technical accuracy for an attack on your solution.
|
Ever hear the story about the lost helicoper pilot and the IBM'er? |
Yes I have. I resent the comparison.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jul 31, 2013 7:29 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
Vitor - I am not complaining about your post. I am "debating" with Jeff.
I had a response (indexed on correlid) queue shared by 2000 concurrent MQ clients once - worked fine. (Mainframe QM and desktop clients if you're interested).
Try it (large scale pulling) and see. I've never found any problems. I like to offer simple solutions - as per Mr Occam. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 31, 2013 7:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| I had a response (indexed on correlid) queue shared by 2000 concurrent MQ clients once - worked fine. (Mainframe QM and desktop clients if you're interested). |
I can see how this scales well if your qmgr is on z/OS, firstly because z/OS subsystems have a lot of grunt and secondly a z/OS queue manager has a unique ability to build indexes and do keyed reads on messages. What happens if the qmgr is on distributed because the site has no z/OS?
| zpat wrote: |
| Try it (large scale pulling) and see. |
As I said, I have and it works great until you hit resource constraints.
| zpat wrote: |
| I've never found any problems. |
Have you tried this large scale pulling on a non-z/OS platform?
| zpat wrote: |
| I like to offer simple solutions - as per Mr Occam. |
Simple solutions are great for simple situations. The issue (which I see as the crux of the debate with mqjeff) is that you're proposing this as a load balancing solution which negates the need for a WMQ cluster and is cheaper because you save license costs (significant if you're using z/OS). The point which I at least am attempting to make is that this technically viable and perfectly valid solution you're proposing has limitiations which the less expereinced readers you alude to may not immediately notice & will come a cropper over later.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jul 31, 2013 8:07 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
The indexing is only need for selective matching.
If unconditional pulling (what I call in my humble and clearly very amateurish way - load balancing) then no indexing (and no z/OS) is needed.
I have never run into problems with large scale usage and it's better for people to consider simple solutions before complex ones.
However clearly my pragmatism is not welcome here. So be it. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jul 31, 2013 8:11 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| zpat wrote: |
| I like to offer simple solutions - as per Mr Occam. |
What did Mr. Occam finally decide on to get that shave?
_________________
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 |
|
|
| Vitor |
| Posted: Wed Jul 31, 2013 8:19 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| However clearly my pragmatism is not welcome here. So be it. |
Your pragmatism is very welcome & I'm looking for a rebuttal to my assertion that you can't scale by sticking n000 client connections onto a single queue manager and/or process significant message volume through a single queue manager given disk I/O, logging & other issues.
| zpat wrote: |
| I have never run into problems with large scale usage |
So quote examples. Prove me wrong (I can get you any number of witnesses who've seen me being wrong). Quote OS, machine resource, achieved throughput, number of app servers & their connection pool size.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 31, 2013 8:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| it's better for people to consider simple solutions before complex ones. |
And what I'm considering at the moment is a big WMQ cluster of Linux based queue managers because I'm got to crank TPS so if there's a way of grouping app servers round one of these things and (as you correctly point out) saving license (and set up time) I'm very much in favour.
@lancelotlinc - we're on Linux because we're on Linux. This has to be stood up by the end of the year so POWER is not an option. I want you to know we did consider it. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jul 31, 2013 8:25 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
Come off it, every design has some limitation. I didn't say it would work for any scale implementation.
If I recommend a car, it doesn't mean it will carry 200 tonnes at 200 mph - extreme requirements (a) need to be stated and (b) will always require special consideration.
If you are going demand evidence that a solution has no limitations for every response, then I really don't have the inclination to participate further on this forum.
Quick and free advice, is always going to be a starting point. But usually the people on here are looking for initial solutions, not fully worked out to be suitable for all situations without any limits.
So the distraction of whether "load balancing" is the perfectly accurate term to use is simply wasting their time and mine. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 31, 2013 9:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| So the distraction of whether "load balancing" is the perfectly accurate term to use is simply wasting their time and mine. |
We can call it "load sharing" if that helps.
I'm still interested in your experience of how far you think you can push a single queue manager in terms of grouped app servers.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jul 31, 2013 11:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
Come off it, every design has some limitation. I didn't say it would work for any scale implementation.
If I recommend a car, it doesn't mean it will carry 200 tonnes at 200 mph - extreme requirements (a) need to be stated and (b) will always require special consideration.
If you are going demand evidence that a solution has no limitations for every response, then I really don't have the inclination to participate further on this forum.
Quick and free advice, is always going to be a starting point. But usually the people on here are looking for initial solutions, not fully worked out to be suitable for all situations without any limits.
So the distraction of whether "load balancing" is the perfectly accurate term to use is simply wasting their time and mine. |
I'm not demanding any of that.
I'm not trying to waste anyone's time.
I'm just trying to point out that calling load sharing by the name of load balancing can lead to dangerous misinterpretations by executives who don't know the difference between an eyelet and an aglet and can't be trusted to tie their own shoes even if they have velcro fasteners.
The original post said "I need to do LOAD BALANCING without using MQ Clusters".
I said "You can't. The only thing that MQ gives you for LOAD BALANCING is MQ Clusters.".
If management expects *LOAD BALANCING*, then they need to use MQ Clusters.
If you give them load sharing when they asked for load balancing, and it doesn't actually balance the load, someone's going to be in for trouble.
It seems helpful and useful to warn people of this. It seems helpful and useful to be clear on the distinction.
Again, I think everything you've said here is helpful and useful, I'm just being particular that it's not actually balancing the load.
Because of the above point that calling it a hamburger when it's got 20% horsemeat may cause people to be upset. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jul 31, 2013 11:22 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
| That's fine Jeff - if you think that's an appropriate attitude. Personally I think some of the responses to people here are quite inappropriate. Maybe you have the time to be perfect, I have other priorities for my spare time. Since you always want the final word, be my guest. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 31, 2013 11:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| Since you always want the final word, be my guest. |
I want at least one more word on your scaling expereinces...
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
