Hi,
When I first read too fast the TTL feature of the flush, I didn’t
understand it as it actually is but as something that could be a nice
feature.
The main idea is to flush the cache in a smooth way: i.e. you ensure
that after this flush operation, no data older than what you defined
is in the
By the way, has anyone already tried to quantify in a *more
scientific* manner the actual extra memory we should let on a box to
be sure memcached won't swap ?
I guess memcached related overhead should be proportional to the
expected number of connection and their traffic. I guess this is about
t
any better chance for the 1.3 if I make it as a possible 0 extra cost
feature like the CAS? ;-)
Jean-Charles
On Mar 20, 8:20 am, dormando wrote:
> We're going to pass on the patch for now. It's a bit much of a corner case
> for the general release.
>
> thanks to folks for taking the time to pro
Hi,
sorry, I haven't put it in production :-P but I played a little bit
with it and I have one strange behaviour when using the binary
protocol.
With small items (10 bytes key / <100 bytes content), there are some
40ms blackout periods during fetch calls. The duration is always very
stable, it lo
1.3.2 :-)
Anyway, if anyone is aware of such ~40 ms poll latency in old suse
configuration or with kernels<=2.6.16.46-0.12-smp , I am interested.
---
Jean-Charles
On Mar 23, 1:42 am, JC wrote:
> Hi,
>
> sorry, I haven't put it in production :-P but I played a little bit
> wi
On Mar 25, 12:08 am, Dustin wrote:
> What version of libevent are you using? Is it possible that this is
> a factor?
1-4-9, also tested with 1-4-8, the behaviour is the same. I used the
exact same libevent in all the tests (exhibiting latency or not) so I
tend to rule out libevent.
> I'
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
t users of the same application?
>
> On Apr 20, 2:08 am, JC 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.
&g
Hi,
just out of curiosity, what are those tracks?
I was thinking as Jaime per slab class mutex and also static division
of the hashtable with specific mutex for each part; am I in the right
direction?
cheers,
Jean-Charles
On Jun 15, 9:11 am, Toru Maesaka wrote:
> Hi!
>
> Apologies for the late
Hi everyone,
There was some time ago a topic about tag based invalidation. Some
ideas and even possible architecture were mentionned but not
described. Is it possible to know a little bit more about what you
have in mind for this feature? Because the more I think about it, the
more possible uses
By the way, is this patch going to be integrated in the mainline?
I mean, I would understand the whole feature to be kicked out but if
it kept in the official version, the opimized way to do things sounds
better, no?
cheers,
Jean-Charles
On Jun 1, 8:57 pm, Trond Norbye wrote:
> On Jun 1, 2009,
Hi,
With version 1.4.1, when setting verbose mode to 1, with ASCII
clients, it almost outputs nothing while with binary clients, all SET/
GET/... operations are outputted, making this mode unsuitable for
anything else than pure test.
My understanding (or said another way, the behaviour in 1.2.* ;
Hi,
trying to investigate an issue on the replicated delete of
libmemcached, I found out that the no reply delete command is replying
something in case of error (as "key not found"), which makes it pretty
hard for the client library to follow the messages count and not work
as expected in certain
Indeed, I was somehow wondering "why a Q for no reply?" ;-)
Anyway, it makes sense. I guess my issue is fully client side then.
cheers,
Jean-Charles
On 25 fév, 18:38, Dustin wrote:
> On Feb 25, 6:29 am, JC wrote:
>
> > trying to investigate an issue on the replicated dele
14 matches
Mail list logo
