Viewing Development/5178
Full headers

Major security issue: yes  no

Notes:
infrastructure added to HEAD; cachedQueryURL, pcacheNumQueries, pcacheNumEntries exposed in HEAD
Notification:

Date: Tue, 9 Oct 2007 13:20:07 GMT
From: ando@sys-net.it
To: openldap-its@OpenLDAP.org
Subject: [feature request] pcache stats & monitoring

Full_Name: Pierangelo Masarati
Version: HEAD/re24
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (193.203.230.29)
Submitted by: ando


This is a feature request for stats and monitoring capabilities for pcache;
basically:

- the number of cached queries
- the number of cached entries
- possibly, a list of cached queries in cachedQueryURL form
- how many times each cached query was used instead of re-running the request
- the ratio answerable / cacheable for each cacheable query
- some global figure like the average response time (send searchResult time -
start caching time) for each query, and the overall average.

Adding per-query info could be done by either extending the cachedQueryURL
format or by adding a child entry for each cached query (like connections and
other dynamic info).

p.

Followup 1

Date: Mon, 17 Aug 2009 23:30:22 +0200 (CEST)
Subject: Re: (ITS#5178) [feature request] pcache stats & monitoring
From: masarati@aero.polimi.it
To: openldap-its@openldap.org

> This is a feature request for stats and monitoring capabilities for
> pcache;
> basically:
>
> - the number of cached queries

The number of cachedQueryURL values

> - the number of cached entries

not available; maybe cachedQueryURL could carry a x-nentries=<num>
extension

> - possibly, a list of cached queries in cachedQueryURL form

ditto

> - how many times each cached query was used instead of re-running the
> request
> - the ratio answerable / cacheable for each cacheable query
> - some global figure like the average response time (send searchResult
> time -
> start caching time) for each query, and the overall average.

None of the above is available.  The first one is interesting, but it
would require query information to survive its life, and match by
base/scope/filter rather than by queryUUID.

> Adding per-query info could be done by either extending the cachedQueryURL
> format or by adding a child entry for each cached query (like connections
> and
> other dynamic info).

This second option does not seem to be viable, although interesting.  I
fear too much overhead.

It's not clear yet how all of this stuff will need to cooperate with the
new TTR (and bind caching, when available).

p.