[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sapdb-general
Subject:    Re: MaxDB 7.5.0.8 - xserver on Windows - DNS blocking all clients
From:       Edson Carlos Ericksson Richter <edson.richter () mgrinformatica ! com ! br>
Date:       2004-03-30 16:56:39
Message-ID: 4069A6C7.20402 () mgrinformatica ! com ! br
[Download RAW message or body]

May be I'm wrong, and maybe I have this latency and never noticed, but 
our database connections are almost instantaneous... I have two 
programmers working here in Linux machines accessing a default install 
of a Win2K server (without -F option) using this configuration 
(/etc/hosts with info about SapDB server name in each workstation, and 
%WINDIR%\system\drivers\etc\hosts for fake workstations name in the 
server), and a click in button "test connection" (using JDBC interface) 
shows times of 10millis, sometimes less (using 
System.currentTimeMillis() to measure), to get connected...

Just to check: you is using a file named just "hosts" (without quotes 
and the ".sam" extension that some windows have)? I think you have 
something wrong configured, because the "localhost" fail you have 
mentioned. You can "ping" your server? How many time this takes? And the 
server, can ping the workstations? What is the timing?

Best regards,

Edson Richter


iml-sapdb@i405.com wrote:

> 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 \
> <edson.richter@mgrinformatica.com.br> 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/maxdb?unsub=sapdb-general@progressive-comp.com



[prev in list] [next in list] [prev in thread] [next in thread]