I appreciate your confirmation of the problem. A host file has not proven enough in case of reverse-DNS lookups that MaxDB / SAPDB does. The same behavior has hit us wen reverse DNS was misconfigured or failed. Especially if you are doing a partial subnet network (/28 /29 /30, etc.) in many situations you have to go through your ISP for reverse.
In a corporate envronment with private addressing (where R/3 and SAPDB have been used in the past) this DNS dependence can be fully managed. For someone on a smaller scale dealing with public addressing at a co-location site getting total control can be difficult. As you mention, you end up having to put in your own DNS service and fake entries to ensure total control over the response time and behavior. Our testing on Redhat 9 Linux shows that xserver -F makes a significant performance difference even with a responsive and working DNS server. As much as 50% quicker on a tight loop of tiny queries (single client machine, connection pooling turned off). This seems inefficent to do a DNS lookup each time a client connects, even if it is the same client over and over. Yet this appars to be the default behavior? At least some aged caching of such an expensive resource hit as a DNS lookup makes sense... Even if the -F parameter is introduced for Windows, the word needs to get out on the importance of use. How many times have benchmarks results for MaxDB suffered because someone was using a DNS server with high latency? Or a bad primary DNS and every one times out and goes to secondary? Why would anyone want this DNS lookup in production use? I thought it was just an annoying problem we could deal with and manage... but 2 years of trying to deal with it at multiple hosting sites and I can't help but put the focus on the xserver design. SAP: This is hard-earned customer feedback, please hear it :) Edson, again, I appreciate what you have shared. We are going to do what we can to harden our systems against this problem. Stephen On Tue, 30 Mar 2004 08:45 , Edson Carlos Ericksson Richter <[EMAIL PROTECTED]> sent: >I don't see anything rude in the post... I think you should remeber that >english is not the first language to vast number of people in the list, >and some times we have diffuculty to express ourselfs, and sometime we >appear being rude - but isn't our intention. So keep cool and try to >understand the problem the user is facing, not blaming him by the words >it self. Don't forget that, looking in the past, under beautyfull words >was executed atrocities. > >Stephen, I faced the problem sometime ago, and found no solution, >neither response from Sap guys. I think they are too busy developing and >fixing a large number of bugs in SapDB and are not getting time to >response complex problems. I'm sure they are storing this complains, and >will eventually fix all of them. About the posts about a year ago, I >have about 5 questions without response in the list too, all valid and >reproducible. > >The question about the DNS dependencie is already discussed largelly in >the past. Unfortunatelly, SapDB need either DNS server or a hosts files >with IP/names mapping. In real, SapDB appear be dependent on a service >name resolution. > >A solution you can use is configure a hosts file in >%WINDIR%\system\drivers\etc with mappings for all IP will be accessing >the server (not need be the real workstation names: is just a way to lie >to SapDB), like this: > >127.0.0.1 localhost >192.168.0.1 server >192.168.0.2 workstation2 >192.168.0.3 workstation3 >192.168.0.4 workstation4 > >and so on to the 192.168.0.254 (no map for 192.168.0.255, because it's >broadcast address, and 192.168.0.0 is the network address). This is make >SapDB think that is a resolution service active and working (look, I >supposing that your subnet is 192.168.0). > >The problem is that if you need communication over the internet. Then, >or you map all IP you need, or you should configure a caching DNS (look >for Bind for Windows - if much better than MS Dns). >In some of our clients, using WINS in a NT Domain local network >environment guarantee that a service name resolution is avaliable, and >we had no problems. > >Best regards, > >Edson Richter >. -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
