I am answering to myself ;-) Well, first, this only occurs on old suse boxes (9, 10.1), and above all this seems to be linked to the client rather than the server (targeting the same server from an ubuntu is enough to make the behaviour desappear) so I guess I have nothing to complain about the 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 <jc.redou...@gmail.com> wrote: > 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 looks like an explicitely defined value but I can't find > which one ! > > So, in ASCII protocol, this work fine (no more than at most 1ms gap > between answers from the server): environment seems then ok. I made my > last test with server and client locally to be sure network can be > ruled out. > > On client side, I trace up to the system call: > # 1:30:12 423177 > error= poll(fds, 1, ptr->root->poll_timeout); (40 ms timeout is not in > this variable ;-) > # 1:30:12 461606 > > On server side, (94 is the item on which it blocked) > 1:30:12 422266 > <32 GET item94 (add_bin_header function) > 1:30:12 422386 > > There is definitly something systematic, it happens always when > fetching almost the same item (at most 1-2 items before or after), > always with the same blocking duration. > I haven't been yet down the lowest layer on server side. Is there some > kind of buffering that could cause that ? > I am really doubting this is some os/network latency/buffering, it is > really too reproducible. > > Has anyone an idea what this could be ? > > --- > Jean-Charles > > On 11 mar, 23:46, Dustin <dsalli...@gmail.com> wrote: > > > > > We've just released memcached beta 1.3.2. It's available for > > download immediately at the google code site: > > > http://code.google.com/p/memcached/downloads > > > There is one known bug (UDP support is somewhat lacking), but it was > > recently discovered by client authors attempting to implement the > > protocol, so I think we're good. > > > We have quite a bit of confidence in this release as we've probably > > spent more effort testing it than implementing new features, but I > > wouldn't recommend you immediately switch all of your production sites > > over. I would, however, hope that you'd ignore my recommendations and > > do it anyway (or at least, test it really, really hard). > > > Release notes are below. They're also in beta, so if something's > > wrong (you're not credited properly, or an important new feature was > > overlooked), be sure to let us know so we can get it right before the > > next release. > > > Memcached 1.3 Beta 2 Release Notes > > ================================== > > > Date: 2009-03-11 Wed > > > Table of Contents > > ================= > > 1 New Features > > 1.1 Binary Protocol > > 1.1.1 Client Availability > > 1.2 Performance > > 1.3 Stats > > 1.3.1 New Stats > > 1.3.2 More Granular Stats > > 1.3.3 Removed stats > > 2 Bug Fixes > > 3 Development Info > > 4 Feedback > > 5 Contributors > > > 1 New Features > > ~~~~~~~~~~~~~~~ > > > 1.1 Binary Protocol > > ==================== > > > A new feature that brings new features. We now have goodness like > > CAS-everywhere (e.g. delete), silent, but verifiable mutation > > commands, and many other wonders. > > > Note that the original protocol is *not* deprecated. It will be > > supported indefinitely, although some new features may only be > > available in the binary protocol. > > > 1.1.1 Client Availability > > -------------------------- > > > Many clients for the binary protocol are available. > > > * C > > > libmemcached supports just about anything you can do with a > > memcached > > protocol and is the foundation for many clients in many different > > languages (which you can find linked from the project page). > > > Project page: [http://tangent.org/552/libmemcached.html] > > > * Java > > > spymemcached has very good text and binary protocol support over > > IPv4 > > and IPv6 with a quite comprehensive test suite. > > > Project page: [http://code.google.com/p/spymemcached/] > > > * Protocol Spec > > > NIH problem? Go write your own client. :) > > > [http://cloud.github.com/downloads/dustin/memcached/protocol- > > binary.txt] > > > 1.2 Performance > > ================ > > > Lots of effort has gone into increasing performance. > > > Facebook-inspired contention reduction with per-thread stat collection > > and the Facebook connection dispatch and thread starvation prevention > > contributions helped our scalability. > > > Lock analysis also showed us that we had quite a bit of contention on > > hash table expansion which has been moved into its own thread, greatly > > improving the scalability on multicore hardware. > > > A variety of smaller things also shook out of performance testing and > > analysis. > > > 1.3 Stats > > ========== > > > There are several new stats and some new ways to look at older stats. > > > 1.3.1 New Stats > > ---------------- > > > * Delete > > > The global stats now contain statistics on deletion. > > > delete_hits refers to the number of times a deletion command was > > issued which resulted in a modification of the cache while > > delete_misses refers to the number of times a deletion command was > > issued which had no effect due to a key mismatch. > > > * Incr/Decr > > > Incr and decr each have a pair of stats showing when a > > successful/unsuccessful incr occurred. incr_hits, incr_misses, > > decr_hits, and decr_misses show where such mutations worked and > > where > > they failed to find an existing object to mutate. > > > * CAS > > > CAS stats are tracked in three different ways: > > > + cas_hits > > > Number of attempts to CAS in a new value that worked. > > > + cas_misses > > > Number of attempts to CAS in a value where the key was not found. > > > + cas_badval > > > Number of attempts to CAS in a value where the CAS failed due to > > the > > object changing between the gets and the update. > > > * slab class evicted time > > > Per slab class, you can now see how recently accessed the most > > recent > > evicted data was. This is a useful gauge to determine eviction > > velocity on a slab so you can know whether evictions are healthy or > > if > > you've got a problem. > > > 1.3.2 More Granular Stats > > -------------------------- > > > Where possible, stats are now tracked individually by slab class. The > > following stats are available on a per-slab-class basis (via "stats > > slabs"): > > > * get_hits > > * cmd_set > > * delete_hits > > * incr_hits > > * decr_hits > > * cas_hits > > * cas_badval > > > (misses are obviously not available as they refer to a non-existent > > item) > > > 1.3.3 Removed stats > > -------------------- > > > "stats malloc" and "stats maps" have been removed. > > > If you depended on these commands for anything, please let us know so > > we can bring them back in a more maintainable way. > > > 2 Bug Fixes > > ~~~~~~~~~~~~ > > > * Build fixes on ubuntu (gcc and icc) and FreeBSD > > * bad interaction with cas + incr (bug 15) > > * setuid failures are reported properly at daemonization time > > * decr overflow causing unnecessary truncation to 0 (bug 21) > > * failure to bind on Linux with no network (i.e. laptop dev) > > * some memcached-tool cleanup > > > 3 Development Info > > ~~~~~~~~~~~~~~~~~~~ > > > We've added a bunch of tests and new code coverage reports. > > > All included code in this release has been tested against the > > following platforms (using the in-tree test suite): > > > * ubuntu 8.10 (64-bit, both gcc and icc) > > * ubuntu 8.04 (32-bit) > > * OS X 10.5 (ppc and intel) > > * OpenSolaris 5.11 x86 (with and without dtrace) > > * FreeBSD 7 x86 > > > 4 Feedback > > ~~~~~~~~~~~ > > > Please try this version. Make it suffer. Report feedback to the list > > or file bugs as you find them. > > > * Mailing List: [http://groups.google.com/group/memcached] > > * Issue Tracker: [http://code.google.com/p/memcached/issues/list] > > * IRC: #memcached on freenode > > > 5 Contributors > > ~~~~~~~~~~~~~~~ > > > The following people contributed to this release since 1.2.6. > > > Note that this is based on who contributed changes, not how they were > > done. In many cases, a code snippet on the mailing list or a bug > > report ended up as a commit with your name on it. > > > Note that this is just a summary of how many changes each person made > > which doesn't necessarily reflect how significant each change was. > > For details on what led up into a branch, either grab the git repo and > > look at the output of `git log 1.2.6..1.3.2` or use a web view. > > > * Repo list: [http://code.google.com/p/memcached/wiki/ > > DevelopmentRepos] > > * Web View: [http://github.com/dustin/memcached/commits/1.3.2] > > > 104 Dustin Sallings > > 49 Trond Norbye > > 32 Toru Maesaka > > 31 dormando > > 8 Steve Yen > > 7 hachi > > 6 Aaron Stone > > 6 Brian Aker > > 4 Victor Kirkebo > > 2 Ricky Zhou > > 1 Jonathan Bastien-Filiatrault > > 1 Evan Klitzke > > 1 Eric Lambert
