2

I must say I was a little mis(un)-informed about the MySQL Memcached plugin which offers the same NoSQL like access to InnoDB tables as HandlerSocket, I had only had experience with entirely standalone memcached servers in cacheing scenarios.

We're using HandlerSocket quite heavily, as it provided a massive increase in IO, and from the original papers on the subject (at the time), it was actually faster than traditional memcached access, thus why we pursued it.

However in learning that the new memcache plugin serves the same purpose now, I went searching for benchmarks, comparisons, or even cock-eyed opinion, but wasn't able to find any specifically addressing both.

I'd like to know if anyone has had experience with both, switched to/from either and what their experiences were?

1

Someone make this bench: http://mimdl.tumblr.com/post/115308901909/benchmarking-handlersocket-mysql-innodb-memcached

  • Get Operation with HandlerSocket was completed in 1.20499610901 Sec, i.e; making 8,299 QPS (Queries per second)
  • Get Operation with InnoDB Memcached Plugin was completed in .93115 seconds i.e; making 10,739 QPS
  • Select Query for MySQL took 333.834 seconds which is considerably low

But there is 10000 small select, not one big.

2

I would recommend using InnoDB memcached over Handlersocket. The advantage of InnoDB memcached is that:

  • It uses a standard memcached protocol, with drivers available for many programming languages.

  • It does not automatically allow access to all tables in your database, but instead tables 'opt-in' via a mapping containers table.

  • It has a stated support policy of 8 years. MySQL 5.6/5.7 support already exists for InnoDB memcached, and these version upgrades are required to unlock many of the scalability enhancements.

  • Thanks for chiming in Morgan. I'm hoping you can expand with more experience on your answer. My first reaction is, the first point doesn't matter, it's not like we're choosing prior to using either, like I said we're already heavily invested in handlersocket, it will be a LOT of work to move over but that's not to say that we wouldn't if it's in our best interest. The only numbers I've seen were early on but handlersocket still left memcache in the dust, has that changed now that it's baked in so to speak? – oucil Jun 14 '14 at 8:46
  • The second point is more interesting but again not sure it matters all that much since we're in an EC2 Virtual Private Cloud, and the DB is inaccessible to anything but our app servers. – oucil Jun 14 '14 at 8:48
  • 1
    On performance: I don't have direct comparison numbers, but in MySQL 5.7 InnoDB memcached can achieve 1.1 million requests/second. See: dimitrik.free.fr/blog/archives/2013/11/… – Morgan Tocker Jun 15 '14 at 4:26
  • On importance of API/protocol: if does simplify development environments as well. Maybe not enough to justify migrating, but wins in an apples to apples comparison. – Morgan Tocker Jun 15 '14 at 4:31
  • 1
    To clarify Dimitri's comment a little: The locking he was referring to became hot at very high core-counts (48 cores), while most EC2 instances will have far fewer cores. Mutexes are common to all DBs trying to control concurrent access. In the absence of benchmarks, I would not rely on HS automatically being better. – Morgan Tocker Jun 16 '14 at 16:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.