Drop-In Replacement for Memcached

Re:Drop-In Replacement for Memcached by maxmcd on Sunday December 12, 2021 @08:08PM (#29535452)

memc has a measuring performance section: https://github.com/memc-rs/memc-rs#measuring-performance

As an arbitrary example, on my machine if I run memtier_benchmark like so:

    memtier_benchmark --port=11211 --protocol=memcache_binary \
      -t 4 --ratio=1:1 --pipeline=9 -c 16 \
      -d 100 --key-pattern=S:S --key-minimum=1 \
      --key-maximum=1000000 -n allkeys

I get the following results:

    memc: 63999483 ops, 587092 ops/sec, 51.39MB/sec, avg 0.82 msec latency
    memcache: 63999936 ops, 2391777 ops/sec, 209.34MB/sec, avg 0.24 msec latency

memtier_benchmark also prints out more detailed stats, but I couldn't get those to work for memc. Not sure what's going on there.

If we set the set/get ratio to 1:10 (maybe more realistic), they get much closer:

    memc: 6399480 ops, 639989 ops/sec, 28.45MB/sec, avg 0.67 msec latency
    memcache: 6399623 ops, 1291566 ops/sec, 57.41MB/sec, avg 0.40 msec latency

[ Parent | on HN ]

Re:Drop-In Replacement for Memcached by injinj on Monday December 13, 2021 @08:17PM (#29546985)

A wireshark capture shows that memcrsd is breaking up the response packets, not optimizing network, sending a lot more packets than memcached. With the 100 byte size, memcached is packing 10 PDUs per packet and memcrsd is doing 1.

Using memtier_benchmark --pipeline=1 with "memcached -t 1" and "memcrsd -r 1" shows almost identical results (141943 vs 136550) on my machine (keys 1 -> 100000). The network is where most of the CPU is spent in both memcached and memcrsd cases.

I'm slightly impressed with memcrsd/rust scaling, 32 runtimes with 16 memtier_benchark threads with pipeline=9 can produce 4 million ops/sec. They need to fix the networking parts.

I think most will use horizontal scaling anyway, and simply shard the memcached's and skip the threading concurrency. Multiple memcached's with client side sharding is hard to beat.

[ Parent | on HN ]