mecached - text protocol?

[Brad Fitzpatrick]

On Fri, 16 Jul 2004, Anatoly Vorobey wrote:

> On Fri, Jul 16, 2004 at 02:05:50PM -0500, Andy Bakun wrote:
> > Is there a list of currently pending
> > bottlenecks that will eventually be taken care of?
>
> We don't know of any. memcached was designed to, first and foremost,
> handle protocol requests as quickly as possible, and it never waits for
> anything but network in those code paths. Considering the fact that
> even a very, very busy memcached server has very low CPU usage
> percentage, it's safe to conclude that everything memcached does on
> its own in the critical code paths is completely dwarfed by
> network-related delays.
>
> The one major change we're working on - moving to a different
> memory allocation model - would result in saving memory, not
> speeding memcached up.
>
> However, currently memcached's stability and speed come at a rather
> large price of memory waste.

For example, only 65% of all LiveJournal's memory is used usefully.  The
other 35% is inter-object 'waste'.

To do efficient memory allocators that don't get externally fragmented,
you need one of two properties:

  1) fixed size allocations
  2) short lifetimes

Memcached has neither, which is why we need to use slabs and intentionally
fragment internally.  (But this lets us do guaranteed O(1) allocations at
all times.)

With the new "bulldozer allocator", there will be no concept of slabs or
memory classes, and we should get much, much tighter memory user.

- Brad