So far, I hadn’t had the time to test it intensively. It helped me understand some JRuby internals though. Maybe you have the time to do the benchmark again?

You’re right, though, my results are around 20k ops per second.

                                          user     system      total        real
set: fake                             0.165000   0.000000   0.165000 (  0.165000)
set: xmemcached:bin                  13.383000   0.000000  13.383000 ( 13.383000)
get: dalli:bin                       24.084000   0.000000  24.084000 ( 24.084000)

get: dalli:bin                       22.399000   0.000000  22.399000 ( 22.399000)
get: fake                             0.194000   0.000000   0.194000 (  0.194000)
get: xmemcached:bin                  12.918000   0.000000  12.918000 ( 12.918000)

I just added a “fake” client (Java class accepting the same args as other clients). We clearly see the overhead (160ms for nothing is not that good) but it wont help turning the benchmark around.

If we look at the benchmark over here, single threaded mode is always below 10k ops/second, which is rather slow compared to your results using libmemcached, as far as I understand this.

Any ideas?

Maybe you could test the speed of the integration itself with a do-nothing Java stub?

Both libs where using the binary protocol and a single server. I did not implement any marshaling. I used the JRuby parameters --server --fast -J-Xmn512m -J-Xms2048m -J-Xmx2048m.

The result is somehow sad:

                                          user     system      total        real
set: dalli:bin                       16.387000   0.000000  16.387000 ( 16.387000)
set: xmemcached:bin                  12.662000   0.000000  12.662000 ( 12.661000)

get: dalli:bin                       17.376000   0.000000  17.376000 ( 17.376000)
get: xmemcached:bin                  12.202000   0.000000  12.202000 ( 12.202000)

That’s 4k gets a second for xmemcached.

I did some tuning (disabling serialization, tcp nodelay, changing the tcp buffer size) aswell, but the changes aren’t significant. I’m a bit disappointed with the single threaded performance of xmemcached. With 300 threads, each doing 10k loops I get the following results:

set: dalli:bin                        3.989000   0.000000   3.989000 (  3.989000)
set: xmemcached:bin                   2.537000   0.000000   2.537000 (  2.537000)

It can’t be the Ruby code slowing it all down in this case.

It’s the same kind of discussion than Tanenbaum vs. Torvalds (micro-kernels vs. macro-kernels). History proved Torvalds right so far. I still think Tanenbaum’s vision is theoretically better but sometimes we have to trade off local simplicity, elegance and low coupling for performance, productivity or global simplicity.

I’m originally a network engineer so the best example I have for this is the TCP/IP stack vs. the ISO stack. TCP/IP won because it broke design rules and increased coupling, resulting in a simpler architecture overall. Yet it’s still a layered architecture at its core.

Ultimately I think you’re right: it’s obviously better to re-use what you have than to re-invent the wheel all the time or duplicate things. We just have to be careful not to end up having all our blocks depending on all the other blocks just because it allows optimal re-use.

To sum up I’d say overall complexity arises from three main things: the number of parts, the size of parts and the number of links (dependencies) between the parts. Because you don’t have to think of all the system all the time, what really matters is global complexity (number of parts + total number of links) and maximum local complexity (for each part, size of the part and number of outgoing + incoming links). It’s up to the system designer to assign weights to those things and make trade-offs.

I think you should be concerned more about multiplicative complexity than whether the coupling is loose or tight. Software is a multidimensional world where nice API boundaries are often insufficient for productivity. If your system is above the threshold of human comprehension, hope that your early encapsulation choices were right, because now you’re stuck with them forever.

I have inflicted some awesome performance improvements on the world by tightly coupling two components into a single component that serves simultaneous, orthogonal goals.

Say you need X and Y to do A, B and C. If you combine X, Y, A, B and C because they overlap you end up depending on A and C to do B. A good example of this is “I can do everything” libraries, eg. OpenCV or Boost.

I think that if you’re working on a project with a reasonable number of moving parts, then fine, reduce duplication as much as possible and make it possible for somebody to understand how the system works. But if the system becomes larger, focus on simple, well-defined APIs and work with black boxes. If that means that you have to duplicate code (eg. in the server and its client(s) for a web service) then that’s the price to pay.

I think we agree on this: paradoxically, simplicity matters are complicated.