Bug 200870

Summary: gethostbyname_r() call takes more time in RHEL 3 than Red Hat 7.2
Product: Red Hat Enterprise Linux 3 Reporter: Yi Tao <tonyit>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED WORKSFORME QA Contact: Brian Brock <bbrock>
Severity: urgent Docs Contact:
Priority: medium    
Version: 3.0CC: drepper
Target Milestone: ---   
Target Release: ---   
Hardware: i586   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-01 12:10:17 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Yi Tao 2006-08-01 02:18:15 EDT
Description of problem:

A measure of the time taken to call gethostbyname_r() turns out that this API 
takes significantly more time to return than Red Hat 7.2.

Also the recent upgrade from Red Hat 7.2 to RHEL 3 turns out that, the time 
taken by gethostbyname_r() is not as stable/consistently low as previously in 
Red Hat 7.2.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Get system time before calling gethostbyname_r();
2. Call gethostbyname_r();
3. Get system time after calling gethostbyname_r();
4. The time taken by gethostbyname_r() is the difference between system times 
of step 3 and step 1.

It is expected to call multiple domain names under both RHEL 3 and Red Hat 7.2

Actual results:
It takes longer time on RHEL3 than on Red Hat 7.2. Also the time used by 
gethostbyname_r() for different domain names on RHEL3 are more diverse than on 
Red Hat 7.2

Expected results:
RHEL3 should be consistently low as, and even lower than Red Hat 7.2 

Additional info:
Comment 1 Ulrich Drepper 2006-08-01 12:10:17 EDT
The implementation does what it has to do.  For DNS lookups the time is entirely
dominated by the network traffic.  There is nothing to change here.
Comment 2 Ulrich Drepper 2006-08-01 12:12:11 EDT
*** Bug 200869 has been marked as a duplicate of this bug. ***