As i know, some internet companies adopt Memcached as fast-access
supporting. it's true that Memcached has get great success.
But, l have to say: Memcached has much to be improved. the need of
protocol switching is nature for long connection access. how could
you prevent a client from doing all kinds of things memcached declared
support just by one connection? i would rather believe that
several pre-memcached scheme like moxi/magent would likely maintain
long-connection-socket-pool, despite of which protol their clients
prefer.

Besides, it's a pity that Memcached can't support shared memory(on
Linux platform). the whole data-cache will All-lost just by updating
Memeached
when neccessary. of course you can say it's just a temporary cache,
just cater for very-fast accessing.... but, we should keep pace with
times because
Memcached is so popular and widely used, shouldn't we?

thank you!



On 10月30日, 上午2时38分, Dustin <[email protected]> wrote:
> On Saturday, October 29, 2011 6:40:59 AM UTC-7, Peter J. Holzer wrote:
>
> > Why would you want to switch protocols in the middle of a connection? Is
> > it documented that this is possible? Unless it is I wouldn't consider
> > the fact that you have to stick with the protocol you have initially
> > chosen as a serious bug.
>
> I've forgotten to respond to this a couple of times now... Sorry about that.
>
> I agree with the above, but will provide some more detail:
>
> 1. The binary protocol has a superset of the functionality of the text
> protocol.  If you can use both, just use binary.  If you find something
> that invalidates this assertion, *that* is a bug.
>
> 2. Dynamically switching protocols would be more expensive and only benefit
> this test.  One of the benefits of the binary protocol is knowing exactly
> how many bytes to read process at each step.  It's *possible* to make an
> efficient implementation of a dynamic protocol switching memcached sever,
> maybe even to do so efficiently, but we'd need a really hard sell on the
> benefits and an inability to find an alternative.
>
> Also, it's a bit rude to send an all-caps subject on an email to a bunch of
> people.  This isn't "very serious" and hasn't affected any one of the
> billions of memcached requests that servers processed while I was writing
> this sentence.

Reply via email to