Theoretical set assoc cache org performance boosts?
sgrimm at facebook.com
Fri Dec 28 06:18:47 UTC 2007
I doubt that would make the network round-trips any faster, and
network delay is, to be very conservative about it, four or five
orders of magnitude greater than the total request processing time
inside the server. You could reduce the server's processing time to
zero and it would have no measurable effect on response times or
throughput from the client's point of view.
Of course, it's open source and you're welcome to experiment; nobody
would say no to a significant performance improvement. But I really
doubt there's much to be gained there.
On Dec 27, 2007, at 9:59 PM, Brian P Brooks wrote:
> To my understanding, at the server level, Memcached is implemented
> by a fully associative cache -- most likely using a LRU stack for
> overwriting comparisons. Would it be theoretically beneficial if
> Memcached were to use a 2 or 4 way set associative cache? Of course
> there would be some changes i.e. would have to statically alloc RAM
> so it could partition it's blocks.
> But, this would definitely help for apps that cache for speed rather
> than cache hit reliability.
> The only way I could see implementing any sort of direct mapped /
> set associative cache organization other than specifying the blocks/
> partitions you write to in your application (ie spec'ing out the
> direct mapped design in your application). Although, I could see
> how this could give you more control of the cache, and could
> probably result in faster caching performance (both reads and
> writes), but lower hit rates.
> Any thoughts?
> Brian Brooks
> Cell: (303)319-8663
More information about the memcached