Re: [Chromium-dev] Chromium start-up time

[<aac...@ad...>]

Hello,

Yes, I figured it was trying to access a non-local network.  I asked because someone was trying to tell me that it was unnecessary for Chromium to try to qualify the hostnames, that the router would take care of that automatically.

Brian's idea for adding the 'qualify-hostnames' as a configuration option sounds like a good idea.

Alicia



> From: Brian Paul <bri...@tu...>
> Date: 2004/09/02 Thu PM 12:22:50 EDT
> To: chr...@li...
> Subject: Re: [Chromium-dev] Chromium start-up time
> 
> Brian Paul wrote:
> > aac...@ad... wrote:
> > 
> >> Hi,
> >>
> >> We currently have a 20 node display that we use with Chromium.  All 20 
> >> nodes, including the Mothership and CRAppfaker run on Windows through 
> >> Cygwin. 
> >> I won't go into excruciating detail about our configuration except to 
> >> say that we use one TileSort spu and 20 render spu's, that are added 
> >> and configured through their appropriate nodes.
> >>
> >> The problem we noticed is that the start-up time to initialize all 20 
> >> displays, plus the CRAppfaker with the Mothership was extremely slow, 
> >> taking more than 3 minutes execution time.
> >>
> >> I traced at least part of the problem down to the Mothership.py file 
> >> and the __qualifyHostname__ function.  It was spending 4.5 seconds to 
> >> sit on the call to socket.getfqdn(host).  We did not have DNS set up 
> >> so I believe it was sitting on this call to fully qualify the host 
> >> name and timing out after 4-4.5 seconds.  Also, this function was 
> >> being called twice per display node via the do_acceptrequest and 
> >> do_connectrequest functions.  Therefore, this was adding alot of time 
> >> to wait for all of the displays to initialize.  Could you please 
> >> explain why it needs to fully qualify the name??  I'm not sure I 
> >> understand why it needs to do this since if we just return immediately 
> >> with the hostname that is passed in, it works just fine. 
> >> Thanks,
> >> Alicia
> > 
> > 
> > It looks like that code was a patch from Joel Welling that I checked in 
> > last December.
> > 
> > Maybe Joel can provide some info.
> 
> Joel replied and asked that I forward this info to the list:
> 
> 
> 
> > Well, __qualifyHostname__() does a table lookup, which should be quite fast.  
> > If it fails to find the hostname in that list (__hostPrefixPairs__) it does a 
> > socket.getfqdn(host).  I had to add the lookup to facilitate connecting to 
> > Argonne's vis nodes from outside.  I believe the socket.getfqdn() was in the 
> > server logic before my mod, but not separated off into the 
> > __qualifyHostname__() function.
> > 
> > The cost of taking out the socket.getfqdn() would be that we'd be making 
> > connections based on local domain names instead of global ones, and that would 
> > surely not be good for non-local Chromium networks.  I presume it works fine 
> > for Alicia without the fqdn is that her network is local and all her hosts are 
> > in each other's /etc/hosts tables (or the Windows equivalent).
> > 
> > I remember some discussion about this a while back, but I don't have time at 
> > the moment to search the archives for it.  Alicia, if you don't want to 
> > disable the socket.getfqdn(host) code and if your hostnames have a common 
> > prefix like 'vis', you could add them to __hostPrefixPairs__ as a temporary 
> > work-around.
> 
> 
> If the fqdn() hostname lookup is a real problem, perhaps we could add 
> a configuration option to enable/disable it.  Something like:
> 
> 	cr = CR()
> 	cr.Conf("fully_qualify_domain_names", 0)
> 
> 
> -Brian
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>