[Bug nscd/16104] New: nscd statistics are inaccurate when local client searches cache.

["carlos at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16104

            Bug ID: 16104
           Summary: nscd statistics are inaccurate when local client
                    searches cache.
           Product: glibc
           Version: 2.19
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nscd
          Assignee: unassigned at sourceware dot org
          Reporter: carlos at redhat dot com
                CC: drepper.fsp at gmail dot com

A local client making use of nscd may request via GETFDPW, GETFDGR, GETFDHST,
GETFDSERV, or GETFDNETGR that an mmap-able fd of the entire cache be made
available such that that client can search the cache itself.

This behaviour is the fast path and allows the client to offload some
processing from the server process to the client process, and is in general
faster than waiting for an nscd worker thread to complete the lookup.

The problem is that if a positive hit or negative hit is found in the cache
there is no way to update the server statistics on the successful hit and
therefore in some cases the server statistics are completely inaccurate.

I do not suggest that we slow down the fast path, but the server did receive
one of the GETFD* request packets and therefore should have been able to record
receiving one of those and display that as a statistic.

I propose we display:

%d number of client-side cache searches

This way if you run `getent netgroup foo' in a loop you will at least see this
statistic incrementing showing that the client's are doing all the lookups.
Obviously a failed search via the client of the memory mapped cache means that
the client must fall back on having nscd do the actual lookup and that will
show up in the statistics (usually as a positive cache miss).

-- 
You are receiving this mail because:
You are on the CC list for the bug.