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 <[email protected]> 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
