It can be whatever type of client, hence the imprecision ;-) Here is the use case I have in mind. We have several different applications using the same DB and so the same cache. However, they have very different DB/cache usage patterns, and only share a small amount of data. With current statistics granularity, it is hard to see if one application is using significantly more Memcached, or if one other has a ginificant cache miss ratio ... Databases usually offer per module statistics, this could somehow be the equivalent for Memcached.
I guess in a web application context, application segmentation has no real sense, it would rather be based on the user family. --- Jean-Charles On Apr 20, 7:21 pm, Dustin <[email protected]> wrote: > What are the types of clients you're talking about? Can you provide > a couple of use cases? Are these for different applications, or just > different users of the same application? > > On Apr 20, 2:08 am, JC <[email protected]> wrote: > > > > > Hi everyone, > > > Currently there are many statistics available in memcached, but all > > these statistics are aggregated in a global way or based on their > > hosting slabs. > > This could be useful to also have aggregation based on client type: > > this could helps to have a clear view on the impact/load/behaviour of > > the various clients interacting with the cache. > > > It does not seem really difficult to keep in the connection structure > > a pointer to a "current client type" statistics structure (can still > > be per thread for performance), that would be updated at the same time > > the main statistics are updated. > > The stats command + the identifier of the client type could be used to > > retrieve these statistics. > > The trickest point is maybe how to define the type of the current > > client since there is no handshake like message. Maybe this could be > > done by an additional client call that would give either a name > > identifying a type or directly a type id so that internal connection > > structure is updated accordingly. ("nasty" solution can be to use the > > noop message for that ...) > > > Of course, the number of different possible types would be limited to > > avoid using too much memory ! > > > what to you think of such a feature ? > > > Jean-Charles
