Re: svn commit: r1413451 - /subversion/branches/cache-server/BRANCH-README

On 20.12.2012 02:08, Stefan Fuhrmann wrote:
> The ineffectiveness of our use of memcached in 1.6 had
> prompted the development of membuffer in the first place.
>
> Despite the relevant APR bug that got fixed only recently,
> there are fundamental limitations compared to a SHM-based
> implementation:
>
> * Instead of reading directly addressable memory, memcached
> requires inter-process calls over TCP/IP. That translated into
> ~10us latency. The performance numbers I found (~200k
> requests/s on larger SMP machines) are 1 order of magnitude
> less than what membuffer achieves with 1 thread.

What kind of latency do you expect when you share this cache amongst
several processes that have to use some other kind of RPC and/or locking
to access the shared-memory segment? I'm ignoring marshalling since it
costs the same in both cases.

> * More critically, memcached does not support for partial data
> access, e.g. reading or adding a single directory entry. That's
> 1.6-esque O(n^2) instead of O(n) runtime for large folders.

That's an issue of cache layout. But I concede the point since it's a
time vs. space decision.

-- Brane

-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com