| Author |
Message
|
| serpota |
 Posted: Mon May 11, 2015 3:24 am Post subject: CONNAME - must we use IP or NAME ? |
 |
|
Voyager
Joined: 26 May 2006
Posts: 85
|
My customer wants to know what is the difference
from the efficiency point of view
if we code (in a given CHANNEL)
| Code: |
| CONNAME('ourhostname(1441)') + |
or use an IP instead of the name.
How often does MQ go to DNS to resolve the name into an IP ?
Every message using the channel ?
Thanks. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon May 11, 2015 4:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| What happens when you test the differences? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon May 11, 2015 4:50 am Post subject: Re: CONNAME - must we use IP or NAME ? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| serpota wrote: |
| How often does MQ go to DNS to resolve the name into an IP ? |
Every time the channel starts.
Also point out to your customer that any overhead introduced by the channel doing a DNS lookup is trivial compared to the overhead of changing hard coded IP addresses in the channel definitions, or the time lost tracking down connection problems when an IP address that's absolutely positively 100% static changes as a result of a network change that can't possibly cause that sort of change.
If your customer is that worried about SLA and the effect a DNA lookup would have (even if we were doing the lookup once per message) they should probably not be using network and have everything on a single server! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 11, 2015 4:52 am Post subject: Re: CONNAME - must we use IP or NAME ? |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| lookup would have (even if we were doing the lookup once per message) they should probably not be using network and have everything on a single server! |
Or at least improve the performance of their DNS server. |
|
| Back to top |
|
|
| zpat |
| Posted: Mon May 11, 2015 5:02 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Windows hosts will cache DNS resolutions anyway.
So will Unix if you enable the NETCD daemon.
_________________
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 |
|
|
| gbaddeley |
| Posted: Mon May 11, 2015 7:31 pm Post subject: Re: CONNAME - must we use IP or NAME ? |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| serpota wrote: |
My customer wants to know what is the difference
from the efficiency point of view if we code (in a given CHANNEL)
| Code: |
| CONNAME('ourhostname(1441)') + |
or use an IP instead of the name.
How often does MQ go to DNS to resolve the name into an IP ?
Every message using the channel ?
Thanks. |
Best practice is to use host name. MQ resolves it once using the DNS when the channel starts and it opens the TCP socket. From a maintenance point of view, host names tend to change less often than IP addresses and are easier to understand.
_________________
Glenn |
|
| Back to top |
|
|
| serpota |
| Posted: Tue May 12, 2015 9:54 pm Post subject: |
|
|
Voyager
Joined: 26 May 2006
Posts: 85
|
Thanks for your answers.
The truth is I could not find any documentation about the moment the DNS is used to resolve the hostname into a IP.
I think customer will be satisfied with the "theoretical" answer.
There is no way we can measure the performance difference between both configurations. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue May 12, 2015 11:23 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
So cache it and stop worrying about it.
_________________
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 |
|
|
| mqjeff |
| Posted: Wed May 13, 2015 4:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| serpota wrote: |
| There is no way we can measure the performance difference between both configurations. |
Then why does the customer care?
There are many ways you can measure the performance.
You can write your own application that sends messages across the channel with a meaningful timestamp and compare the message on the receiving end with the current timestamp.
You can do a manual test where you look at how long a message takes to move across the channel.
You can use MQ statistics...
and other ways at the OS level...
But if you can't measure it, then why does the timing matter? |
|
| Back to top |
|
|
| serpota |
| Posted: Thu May 14, 2015 9:55 pm Post subject: |
|
|
Voyager
Joined: 26 May 2006
Posts: 85
|
zpat - I never had worried about the performance in either case, but the customer does, and I am to provide an answer
mqjeff - customer pays lots of money for our support, so they (think they) have the right to ask a clever (?) and theoretical question, maybe only to justify their salary. I have opened lots of PMRs just to ask the lab "what would happen in this environment if we double the load on the same hardware ? or where are the limits of this configuration ? how is we dont reach the theoretical throughput? (usualy involving MB, of course)
And I think it is good for me (or for us) to know the intimal details of the product functioning - max channel speed, triggering response times, filesystem overload (as we try to use NFS), DNS resolution details, etc
Another thing I think is that MQ documentation has worsened a lot since v5 to v8.
Thanks. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu May 14, 2015 11:02 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
So tell the customer to use DNS caching and stop worrying about it.
_________________
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 |
|
|
| mqjeff |
| Posted: Fri May 15, 2015 4:16 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The documentation has changed since v5. It's more consolidated, thankfully, but more broken up into smaller pieces... So you have to read more pages on a single topic - and sometimes you have to poke around in more than one place.
However, I think that the information is more complete than it was in v5, and more in depth.
I understand the kinds of things that a typical MQ administrator or even a team of experts have to respond to from the customer.
But generally, if you can't measure something, it's not clear at all that the answer matters.
If your customer is asking you to measure something, or determine the impact of something - and you don't currently know how to measure it - then, perhaps, you should figure out how to measure it.
Otherwise, I'm glad you're taking your role seriously and making efforts to respond to customer questions and requirements. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri May 15, 2015 5:11 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
There are situations where the ip address is not appropriate or might lead to confusion. If you are using NAT in your network, it could mean that in one subnet your ip is say 10.10.20.15 and in another subnet it is 10.10.40.3.
So if you go advertising the ip to connect to, it means that all participants need to be aware of the NAT tables. Using a host name usually is the better way to go as these NAT problems are then resolved by the DNS attached to the subnet. If you are allowed to use the short name or have to use the qualified name depends on how your network engineers set up the DNS entries.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri May 15, 2015 5:48 am Post subject: Re: CONNAME - must we use IP or NAME ? |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| serpota wrote: |
My customer wants to know what is the difference
from the efficiency point of view ... |
An explicit specification of a static ip address is a far shorter path of machine instructions and network searching than specifying a "name" that must be resolved dynamically - in real time.
In a worst-case, when the channel starts (or restarts) the name might cause the search to leave your local DNS cache, pass to your network-edge DNS server, pass to your ISP's DNS server, pass to your ISP's DNS provider, pass to one of the BIG DNS servers - only to discover that the name is not found. It is possible that the name might resolve, but the resolved ip address is not currently valid (listener failed, NIC card failed, end socket app down, others).
If you know your network-end ip addresses, and they are to remain static for months or years, then stick with explicit ip addresses.
_________________
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: Sun May 17, 2015 5:19 am Post subject: Re: CONNAME - must we use IP or NAME ? |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bruce2359 wrote: |
| serpota wrote: |
My customer wants to know what is the difference
from the efficiency point of view ... |
An explicit specification of a static ip address is a far shorter path of machine instructions and network searching than specifying a "name" that must be resolved dynamically - in real time.
In a worst-case, when the channel starts (or restarts) the name might cause the search to leave your local DNS cache, pass to your network-edge DNS server, pass to your ISP's DNS server, pass to your ISP's DNS provider, pass to one of the BIG DNS servers - only to discover that the name is not found. It is possible that the name might resolve, but the resolved ip address is not currently valid (listener failed, NIC card failed, end socket app down, others).
If you know your network-end ip addresses, and they are to remain static for months or years, then stick with explicit ip addresses. |
Does that mean that if you have NAT you would create 2 (or more) cluster receiver channels, one per IP? if you are really worried about efficiency of the DNS name resolution should you not have all the needed names in the /etc/hosts to bypass the DNS and supply the correct information? This would still allow you to supply a different IP depending on where in the network your host is located...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
