Johannes Schlüter - Comments

James Day: MySQL, Memcache, PHP revised

nospam@example.com (James Day) — Thu, 04 Oct 2012 12:21:14 +0200

For batching, consider the common case where there are many fast queries per page load. Do them all in one round trip on one connection... With memcached API, that may turn out to be doable more quickly querying the database directly than splitting some of the work into memcached itself and some into the database server. James

James Day: MySQL, Memcache, PHP revised

nospam@example.com (James Day) — Thu, 04 Oct 2012 12:17:15 +0200

gggeek, I look at users at a massive place paying attention to connect time optimisation and that tells me that they think it's painful enough for them that they want something done to improve it... Being faster than others is good but we can be even faster... one round trip plus a little per query is what I want to see. Then maybe one round trip for multiple queries carried out sequentially or in parallel, perhaps batched up by a connector transparently. James Day

Johannes Schlüter: MySQL, Memcache, PHP revised

nospam@example.com (Johannes Schlüter) — Wed, 03 Oct 2012 04:19:13 +0200

Yes, the MySQL login will be done when using this plugin, in the current form, anyways. There are some thinkable approaches to eliminate those. Not sure we'll add them, they can have negative side effects ... needs some thinking.

Johannes: MySQL, Memcache, PHP revised

nospam@example.com (Johannes) — Wed, 03 Oct 2012 01:44:24 +0200

Not yet. But might be interesting to add.

Changha Lim: MySQL, Memcache, PHP revised

nospam@example.com (Changha Lim) — Wed, 03 Oct 2012 01:31:33 +0200

Great job! Do you support persist connection?

gggeek: MySQL, Memcache, PHP revised

nospam@example.com (gggeek) — Tue, 02 Oct 2012 03:20:45 +0200

@James avoiding authentication overhead can make sense - even though I consider the mysql connection time and network protocol to be already highly optimized (I compared to Oracle using a standard cms and the difference was huge). But in the example given above, it seems that the mysql login is also done, isn't it? @Johannes sure I will benchmark, and come back with results. Since we're using an ORM, there's a lot of table access based on primary keys. Do you think that mapping all of them (about 100) for memcached access could work?

James Day: MySQL, Memcache, PHP revised

nospam@example.com (James Day) — Mon, 01 Oct 2012 21:46:06 +0200

Nice! Read only transactions are another good opportunity to exploit in 5.6. Either setting autocommit on or using START TRANSACTION READ ONLY. gggeek, consider the round trips of the traditional MySQL SQL login and the CPU cost of the authentication process on the client compared to the CPU cost of a regular expression. The memcached API should be an easy win based on eliminating some round trips. Views are my own, for an official Oracle view, consult a PR person. James Day, MySQL Senior Principal Support Engineer, Oracle.

Christopher Kunz: MySQL, Memcache, PHP revised

nospam@example.com (Christopher Kunz) — Mon, 01 Oct 2012 16:36:13 +0200

"Scaling web servers is simpler than scaling web servers" I presume the second web is supposed to be a DB.

Johannes: MySQL, Memcache, PHP revised

nospam@example.com (Johannes) — Mon, 01 Oct 2012 15:49:59 +0200

Hi about your 1st question: I can tell zou that in the current implementation it is less (as this plugin is using a relatively simple regular expression where the precompiled regexp is cached in PHP) but even if it wasn't you have a benefit: Scaling web servers is simpler than scaling web servers, so when ofloading work this can be beneficial. Though, in general the best answer is: Benchmark it yourself. These performance differences depend on soooooo many things in your setup. Any generic benchmark will not tell you much for your case For the 2nd question: I haven't measured this but the innodb server plugin is relatively low on the server. Directly talking to InnoDB. Therefore it is not using the query cache, but it is using InnoDB 's buffer pool etc.

gggeek: MySQL, Memcache, PHP revised

nospam@example.com (gggeek) — Mon, 01 Oct 2012 08:36:10 +0200

wow, massive! a question though: I imagine that the mysqlnd_memcache extension would add some parsing overhead to every mysql query executed. How can we be sure that this overhead is less than the gain in response time we get from using the memcache-api of mysql instead of its native api? and then a 2nd question: is there any difference in memory usage (both on the php and mysql server sides) for using memcached protocol instead of mysql one? E.g. is data fetched via memcache stored in the mysql query cache?

Wlad: Upcoming talks

nospam@example.com (Wlad) — Thu, 12 Jan 2012 13:23:59 +0100

Konnectoren ist Denglish:)? Richtiges Deutsch hat doch mehr 'K's, d.h Konnektoren?

Hanna: High Performance PHP Session Storage on Scale

nospam@example.com (Hanna) — Tue, 29 Nov 2011 19:40:57 +0100

Haha, I miss the good old time, everything was easier and slower. I like the idea of a central repository.

vlad s.: High Performance PHP Session Storage on Scale

nospam@example.com (vlad s.) — Sat, 19 Nov 2011 18:59:02 +0100

I would cut this post in half.

gggeek: High Performance PHP Session Storage on Scale

nospam@example.com (gggeek) — Fri, 18 Nov 2011 14:10:36 +0100

I remember using phplib for session management too. Those where the days!... well, actually, I was so glad when php native session management came around

Johannes: High Performance PHP Session Storage on Scale

nospam@example.com (Johannes) — Thu, 17 Nov 2011 21:41:24 +0100

Oh, the good old days. Back when my 90 MHz Pentium was good enough to host my site and MySQL 3.23 did all I needed from a database