Yo,
Apologies, guess I stopped sending updates to this list. It's not actually
clear to me how many people still read it. :)
Releases quieted down at the end of last year but will start up again
shortly. Still aiming at monthly cuts with at least small updates.
I started a blog on the main site
Hi all,
Reading memcache documents its clear that it can handle a very heavy load
of traffic. However I was more interested in knowing the bound on how may
updates for a specific key at the same time can memcache handle.
-Shashank
--
---
You received this message because you are subscribed
Internally, there's a per-item lock, so an item can only be updated by one
thread at a time.
This is *just* during the internal update, not while a client is uploading
or downloading data to the key. You can probably do several thousand
updates per second to the same key without problem (like
On Wed, 12 Mar 2014, Joshua Miller wrote:
On Wed, Mar 12, 2014 at 12:43 AM, dormando dorma...@rydia.net wrote:
https://github.com/unrtst/Cache-Memcached/tree/20140223-patch-cas-support
This started as just wanting to get a couple small features into
https://github.com/unrtst/Cache-Memcached/tree/20140223-patch-cas-support
This started as just wanting to get a couple small features into
Cache::Memcached, but I ended up squashing a bunch of bugs (and merging
bugfixes from existing and old RT tickets), and kept adding features.
The repo
https://github.com/unrtst/Cache-Memcached/tree/20140223-patch-cas-support
This started as just wanting to get a couple small features into
Cache::Memcached, but I ended up squashing a bunch of bugs (and merging
bugfixes
from existing and old RT tickets), and kept adding features.
The
On Wed, Mar 12, 2014 at 12:43 AM, dormando dorma...@rydia.net wrote:
https://github.com/unrtst/Cache-Memcached/tree/20140223-patch-cas-support
This started as just wanting to get a couple small features into
Cache::Memcached, but I ended up squashing a bunch of bugs (and merging
Hello all,
In adding support for the sFlow monitoring standard to the latest memcached
(see http://code.google.com/p/memcached/issues/detail?id=202) I used a scheme
for lock-free counter accumulation that might make sense for the memcached
stats counters too.
Background: the memcached
I remember discussing this with Dustin back when I added the threadlocal
counters. Back then I suggested that we would just do dirty reads of the
counters used by the other threads, but we decided that we could might as well
do it the safe way and fix it if it ever popped up with lock
I don't have measurements, sorry. I'm just working from the
finger-in-the-air assumption that even un-contested mutex-locks can cost a
surprising number of cycles. (I think the TOP-KEYs mutex lock is much more
serious because the threads will actually stall over it - that's the kind of
dormando wrote:
Hey,
I wasn't really intending on doing another 1.3-like series. Since the new
protocol was a Big Deal and a Forward Standard we had to give it a lot of
time and a few good public revisions before solidifying on it. I don't
think any of our forward internal changes really
I'm ok with the them in the list also. If the messages are
overwhelming, you could set your account to receive only 1 daily email
containing all the new activity.
On Aug 19, 10:36 pm, Dustin dsalli...@gmail.com wrote:
On Aug 19, 4:00 pm, Syed Ali alisy...@gmail.com wrote:
Hi Guys
I thinks
Hi all,
Since a number of memcached contributors and client authors were in one
place at the Drizzle conference this week in Seattle we had a short
discussion about the release roadmap for stable and development
branches. I captured much of the discussion and it's posted on the wiki:
Hi Guys
I thinks its a bit overwhelming to receive notifications of each commit.
Would it be possible to turn 'em off?
Syed
Ps: we can still subscribe to individual alerts and defects if needed
--
--
-Syed Ali
I'm just fine with them being on there.
It gives much more visibility into the things being done to the code base.
I vote for leaving them turned on..
On Thu, Aug 20, 2009 at 7:00 AM, Syed Ali alisy...@gmail.com wrote:
Hi Guys
I thinks its a bit overwhelming to receive notifications of each
On Aug 12, 6:10 am, Dustin dsalli...@gmail.com wrote:
On Aug 10, 12:13 pm, Ren jared.willi...@ntlworld.com wrote:
Though, it would be nice if SET/CAS ops could return the new CAS
value, I think.
It does in the binary protocol.
Ah nice, well it seems PHP's PECL Memcached extension
On Aug 12, 5:39 am, Ren jared.willi...@ntlworld.com wrote:
Ah nice, well it seems PHP's PECL Memcached extension doesn't support
it.
Wether that is because libmemcached doesn't yet, don't know.
libmemcached definitely does. The bindings just need to be updated.
than you'd
like. Probably best to run those updates through your favorite job
queue.
I see this as a good idea. I think that the failure to update should be
on the step where it puts back the original data with the extended
expiry. If it cannot do this, then starting again will either
On Aug 10, 12:13 pm, Ren jared.willi...@ntlworld.com wrote:
Though, it would be nice if SET/CAS ops could return the new CAS
value, I think.
It does in the binary protocol.
is taking care of the update.
That's an interesting approach. I'd only fear a failure to actually
update the value causing stale data to stick around longer than you'd
like. Probably best to run those updates through your favorite job
queue.
I see this as a good idea. I think
20 matches
Mail list logo
