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.
-Steve
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
http://csel.cs.colorado.edu/~brooksbp/
Cell: (303)319-8663
