cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dariusz Ɓuksza <dariusz.luk...@gmail.com>
Subject Re: [c3 monitoring] Cache overview
Date Thu, 16 Jul 2009 19:33:21 GMT
On Wed, Jul 15, 2009 at 8:43 PM, Simone Gianni<simoneg@apache.org> wrote:
> Hi Dariusz,
> I had a look at your patch. I see the method "listKeys", with the
> description "Removes all cached data". I think this is an error, looking at
> the source it lists cache key names, and does not remove them, while the
> "clear" method does that.

Strange that I've missed that ...

> Apart from this small error, regarding your question, I'm trying to figure
> out what a user will want to see when checking the cache.
>
> I'm brainstorming here, trying to paint a big picture, probably the real
> features will be much smaller, but this could provide you ideas and at the
> same time help identify which ones are most important.
>
> I can think of three possible scenarios :
> - While developing, they see something they don't expect to see, and they go
> check if there is some cached data in the way.
> - While optimizing the application, they go check what happens in the cache,
> if/how they are wasting RAM by caching too much or wasting CPU by not
> caching enough.
> - At runtime, they could access it to see what's going wrong, to recover
> some ram, to clear everything if they just published something really
> important and they want it to appear now.
>
> Given these three scenarios, these are things that may be useful to see via
> JMX, but I don't know which of them are actually achievable or already
> there, so this is an "abstract" POV :
> - The component that stored that entry (it's part of the name already for
> ComponentCacheKey)
> - Which "pipeline" I'm referring to, so that if it's not working properly I
> can check if there is cached stuff.
> - The size of the entry, I see it is possible to obtain it from CacheKey
> with your patch. this is useful if I'm profiling or in desperate need to
> free some ram.
> - When that entry will expire by itself, if it will.
> - Last time that entry has been used (red) from the cache, if ever.

Here you generally refer to single cache entry. But question how to
represent cache entry on JMX tree is still actual. I have two ideas
how we can do that:
- based on URL with they published
- based on pipeline and type of cache

IMHO all features for single cache entry that you mentioned would be
easy to implement.

> Since the cache could contain quite a number of elements, there should be a
> way to isolate keys matching certain criteria. It would be nice to pack
> everything in the name, but all this stuff will not fit in the "name", and
> it is used then as a key for other operations.
>
> .. these are some random ideas :
> - "String getKeyInfo(String keyname)" method, returning all possible data
> about that key as a plain string. Simple to implement, but may be tedious to
> use (call this method once for each key to see it's data).
> - "String[] queryCache(long minsize, Date mintime .......)", matching a
> criteria based on two or three parameters
> - "String[] queryInfo(long minsize, Date mintime .......)", same as before,
> but returns directly the info
> - "boolean clear(long minsize, Date mintime .......)", clean using the given
> criteria
> - you can easily vary on this theme :)
>

Idea of "burst operations" is awesome ! especially with cache
cleaning, I'll look on that in the nearest feature ;)

-- 
Best regards

Blog: http://luksza.org
LinkedIn: http://www.linkedin.com/in/dariuszluksza

Mime
View raw message