public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: 이병욱 <nimdrak@naver.com>, "Carlos O'Donell" <carlos@systemhalted.org>
Cc: libc-help <libc-help@sourceware.org>
Subject: Re: How to compile and use 'nscd'
Date: Fri, 29 Jul 2022 12:41:48 -0400	[thread overview]
Message-ID: <8f2df828-ddb7-a6dc-7a98-cc13cf3b7795@redhat.com> (raw)
In-Reply-To: <91ed2385bf981412d38f3e1cc068a5@cweb012.nm.nfra.io>

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.


  reply	other threads:[~2022-07-29 16:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-24  7:57 이병욱
2022-07-24 13:50 ` Carlos O'Donell
2022-07-24 14:15   ` 이병욱
2022-07-29 16:41     ` Carlos O'Donell [this message]
2022-07-31  9:18       ` 이병욱
2022-07-31  9:20       ` 이병욱

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8f2df828-ddb7-a6dc-7a98-cc13cf3b7795@redhat.com \
    --to=carlos@redhat.com \
    --cc=carlos@systemhalted.org \
    --cc=libc-help@sourceware.org \
    --cc=nimdrak@naver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).