From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 216F33858297 for ; Fri, 29 Jul 2022 16:41:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 216F33858297 Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-441-eECnbNh-Oay6n5BtlUlXcg-1; Fri, 29 Jul 2022 12:41:50 -0400 X-MC-Unique: eECnbNh-Oay6n5BtlUlXcg-1 Received: by mail-qv1-f72.google.com with SMTP id q1-20020a056214018100b0047464a85fc4so3514422qvr.7 for ; Fri, 29 Jul 2022 09:41:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=WaCZbQSOfKTmIrJMeYtnPs/bHXVPsB32yr/zNW4/l7w=; b=NRBvfwwrY7n8oKnPVl3ViKabUHTIYXQE+sGifY/UEF3++6MwaKIIsCIrOquGMMKNQi FiFAoZHJv0mc9/RSGglkKssO038rGS26d7Vym/yBzhMnC25jFCJ6dg20kpcUraydQOM4 T4iBKk3S/CuVfN2PQ/vJWiwTZfEmYsR5iy7w62xwqoFKpTz+chIw3M7hMb9HOiTkBmBb h62mzVD8PpMtRRweLNlWxrBgIWP9TRJ8q7JeXGF0kwAh9m7ovTgpvpcVKbV4Qq+n5h2X xYeJcRpJGe3HuihyPiTn539fdG8KsmvtwblRDa9QllRM19sIh2/wdisF51ApoTmJt41N J6ag== X-Gm-Message-State: ACgBeo3gqqtqqb1WiGRKdngoDq5ipKbr36/T35qk/4C2evd4aUgchkX4 BrLPg0+jIH9Q2hrXYGzpLP1Gs6XEyRtkNRvoidsGpKc8c2yU50TRdvnZSpBeJyjUaZdiE/bI/bb 73KRz/Avo2dVc6eSnpak= X-Received: by 2002:a05:6214:2265:b0:474:8865:7ba2 with SMTP id gs5-20020a056214226500b0047488657ba2mr3921878qvb.98.1659112910028; Fri, 29 Jul 2022 09:41:50 -0700 (PDT) X-Google-Smtp-Source: AA6agR4awsSnwzC2N9UK+OlyI0hnHufrs4vKyD0r7bTgpkCDpmc+FO4TNNikNSmwJseEz7T+tqmz2w== X-Received: by 2002:a05:6214:2265:b0:474:8865:7ba2 with SMTP id gs5-20020a056214226500b0047488657ba2mr3921861qvb.98.1659112909759; Fri, 29 Jul 2022 09:41:49 -0700 (PDT) Received: from [192.168.0.241] (192-0-145-146.cpe.teksavvy.com. [192.0.145.146]) by smtp.gmail.com with ESMTPSA id k6-20020ac80746000000b002f39b99f6a4sm2404165qth.62.2022.07.29.09.41.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Jul 2022 09:41:49 -0700 (PDT) Message-ID: <8f2df828-ddb7-a6dc-7a98-cc13cf3b7795@redhat.com> Date: Fri, 29 Jul 2022 12:41:48 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: How to compile and use 'nscd' To: =?UTF-8?B?7J2067OR7Jqx?= , Carlos O'Donell Cc: libc-help References: <268721506430b9d1fa3e1725d230e59b@cmweb01.nm.nfra.io> <91ed2385bf981412d38f3e1cc068a5@cweb012.nm.nfra.io> From: Carlos O'Donell Organization: Red Hat In-Reply-To: <91ed2385bf981412d38f3e1cc068a5@cweb012.nm.nfra.io> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2022 16:41:55 -0000 On 7/24/22 10:15, 이병욱 via Libc-help wrote: > Thank you for your reply. > > If you know, would you tell me why `CACHE_PRUNE_INTERVAL` is defined > as 15? It is hard to find the reason anywhere. I don't think there is a strong justification for 15s. It could be added as a tunable to nscd.conf. > If it was intended for mitigating the load of the client server with > nscd, I think it is a little large, considering the current server > performance. It limits the CPU usage on the client by pruning the cache at certain intervals. The cache entries themselves, depending on the cache, will have TTL information that can time out on a shorter interval. > I found at JVM environment (JVM has its own DNS caching), It seems > that TTL value close to 0, doesn't have an impact to a client server > performance, to an extent. > > I think if we choose a DNS round robin for distributing the traffic > load, it is inevitable to assign a DNS ttl close to 0. Otherwise, it > can make biased traffic to servers. > > Although I make a A record TTL value below 15, this small TTL value > become meaningless because the client make a dns query at least every > 15 seconds, which is `CACHE_PRUNE_INTERVAL`. Why does it become meaningless? The CACHE_PRUNE_INTERVAL is the interval in which the pruning thread looks for entries with expired lifetime. It is not the interval at which entries are expired, the actual expiry is determined by TTL values. > Is there a design philosophy about `15`? None that we have documented. -- Cheers, Carlos.