Memcache binary protocol support about mcrouter

[lcacciagioni]

Is this issue closed? Binary protocol support will be great

[erulabs]

It looks like PHP7 uses binary protocol for the memcached session handler by default these days. That means you get a pretty ugly error like:

Fatal Error: session_start(): Failed to create session ID: memcached

Since mcrouter doesn't support binary protocol, you'll need to tell PHP not to use it for sessions:

memcached.sess_binary_protocol = 0

So I'm betting this thread will get more and more visitors as people try to put PHP7 and Mcrouter together for the first time.

[Ngo-The-Trung]

I'd like to take on this task

[ndobromirov]

From experience the binary protocol allows for much higher performance (overall) compared to plain text one, mainly because you can then use compression on the data and keys you set in memcacheD instances.

From there you are greatly reducing:

1. The cache storage needs of the system. As a plus-side, you can cache more on the same servers or cache the same with less, saving either further CPU cycles on application layer or some more money in the pocket.
2. The network transfer times for cache reads, as the data is compressed and not a in plain text format it is usually around 10 times smaller (or more). This should improve network related delays and related bottlenecks.

The only problem is that client side will have some more overhead in CPU to consume the data, but that is usually negligible compared to the network delays to fetch it. Thus having compression for memcache is a net-positive performance-wise.

I am a huge +1 on having binary protocol supported in mcrouter. This will allow us to test and experiment with all of it's features. As it is at the moment, we can not use this software, as we depend on compression for our servers to run normally.

[codyja]

Would love to see Binary protocol supported as well. We use it for performance reasons too.

[alikhtarov]

@renchap yes, the Umbrella protocol is something we use internally at Facebook. We don't want to document it in detail, since it probably won't be useful outside of Facebook, and we also want to have flexibility to change the format.
I like the idea of supporting the open source binary protocol, and it wouldn't be too difficult to implement. It would be ideal if we got a pull request for implementing this :)

[nichochar]

Anyone with C++ skills want to tackle this? Maybe we can get some precisions on where in the codebase this change would happen, to make it easier for a contributor to start attacking the problem.

[liyufu]

if the mcrouter currently supports the binary protocol now?
@renchap
if the binary protocol have a good performance to the ascii protocol?

[liyufu]

@renchap

if the binary protocol have a good performance to the ascii protocol?

[ryanmce]

mcrouter does not currently support the memcached binary protocol. It does have a mcrouter-to-mcrouter binary protocol called umbrella, but memcached doesn't know how to parse it, so it's only useful in routing networks.

On Mar 7, 2015, at 3:03 AM, liyufu [email protected] wrote:

@renchap

if the binary protocol have a good performance to the ascii protocol?

—
Reply to this email directly or view it on GitHub.

[amckinley]

Any updates on this? We need binary protocol support before we can use mcrouter.

[alikhtarov]

@amckinley: hi, no updates at this time. By the way, could you share how the binary protocol helps in your case? We're actually evaluating whether to migrate from ASCII to binary internally for memcached - some things we can think of is slightly better parsing performance (due to known sizes), and reply/request matching (less parsing bugs).

[cce]

We use the binary protocol because it seemed easier than worrying about ASCII-encoding binary keys like hashes or UTF-8 strings, and seemed faster as well for the reasons you mentioned. Would love to see support in mcrouter!

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

[mikeKBB]

we currently use the binary protocol with the enyim client, and we were hoping to plug in mcrouter to enable the replication and warm up features. But the ascii only support seems to be a major impediment.

we installed a mcrouter docker container, but on the initial tests the ascii items are timing out. is there some client tweak recommended or required other than specifying protocol is text?

[barryhatfield]

+1

[barryhatfield]

I was poking around in the latest version of the code (by no means am I an expert) and noticed some binary support stuff. Any update?

[jmswen]

@barryhatfield, mcrouter supports a binary protocol (called Caret, if you see that word in our codebase) that has nothing to do with open-source memcached's binary protocol.

Unfortunately, at this point, we have no plans to add support for open-source memcached's binary protocol ourselves since we're happy with using Caret and ASCII internally. But, we would be willing to help guide anyone who wanted to contribute pull requests for open-source binary support.

[andreazevedo]

@Ngo-The-Trung great!

Let us know if you need anything, we will be happy to help.

[mujtabaahmed1991]

I am also interested to work on this, @Ngo-The-Trung lets get in touch.

[ELD]

@Ngo-The-Trung Are you still working on this? If not, I'd be happy to take this track of work up. I'd really like to see mcrouter support the binary memcached protocol, too.

[Ngo-The-Trung]

@ELD please take over

[ELD]

@Ngo-The-Trung Thank you, will do.

[darjisanket]

Any updates on support for binary protocol.

[ndobromirov]

As they've mentioned mcrouter does support binary protocol for transferring data.
This will reduce the network overhead in a case where you have 2-step mcrouter setup like:
box 1: web app + mcrouter1.
Box 2: Memcache + mcrouter2

The communication channel would be like:

• web app -> mcrouter1 (text, unix socket)
• mcrouter1 -> mcrouter2 (binary, non-standard, network)
• mcrouter2 -> memcached (text, unix socket)

I have not tested this but in reality it should reduce network overheads (at least) and allow for all the features to be used.
Will it be faster will likely depend on the workload.