Skip to content
This repository has been archived by the owner on Nov 2, 2021. It is now read-only.

GSoC Information

thinkingfish edited this page Apr 22, 2013 · 3 revisions

Cache Lock Revamp

Summary

Twemcache inherits the multithreaded design and its locking mechanism of Memcached (1.4.4 to be exact). While having great performance and low CPU utilization in general, lock contention is often the bottleneck that prevents Twemcache from taking advantage of the many cores on modern CPUs. Re-designing locking in Twemcache can push single instance throughput to a whole new level.

Background

Please refer to this investigation into Twemcache's scalability and lock contention. There are various locks used in Twemcache, but the most important ones are those used to protect the hashtable(s) and slabs.

Goal

As shown above, the current locking design clearly has room for improvement. We are re-examining how key lookup and memory allocation are implemented, and how locking is woven into these procedures. The goal is to come up with a new, preferrably simple design that realizes as much theoretical gain of a lock-less system as possible.

Approach

To get there, we may need to look into various possible designs, compare their pros and cons, build prototypes and run performance tests against them. It's more important to know how to evaluate a solution and iterate based on results, than coming up with the perfect solution on the first try.

Clone this wiki locally