<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.3" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: LuaSQL fetches results about 15% faster than MySQL Proxy?</title>
	<link>http://pero.blogs.aprilmayjune.org/2008/09/07/luasql-fetches-results-about-15-faster-than-mysql-proxy/</link>
	<description></description>
	<pubDate>Fri, 12 Mar 2010 05:52:57 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.3</generator>
		<item>
		<title>By: pero</title>
		<link>http://pero.blogs.aprilmayjune.org/2008/09/07/luasql-fetches-results-about-15-faster-than-mysql-proxy/#comment-5269</link>
		<dc:creator>pero</dc:creator>
		<pubDate>Tue, 09 Sep 2008 13:16:05 +0000</pubDate>
		<guid>http://pero.blogs.aprilmayjune.org/2008/09/07/luasql-fetches-results-about-15-faster-than-mysql-proxy/#comment-5269</guid>
		<description>Jan, Kay, thanks for your comments.

First of all, my assumptions MySQL Proxy is putting the whole result on LUA stack at once is false, indeed. I corrected that.

I reproduced the tests above on an 8-core-server with 8GB RAM putting the database on another server and using HEAP tables. Then the performance of both MySQL Proxy and LuaSQL was nearly equal, MySQL Proxy being about 2-5% faster. I was not able to see a performance gap of factor 1.6 - perhaps your "internal" 0.7 version has some other improvements? BTW: When is it going to be in SVN?

Kay, thanks for the pointer to LuaSQL + MySQL Proxy issues in high concurrency. I quickly tried to verify that by using "-c 10" switch in mysqlslap. But I could not see a drop in the LuaSQL performance. 

As said above, I am planning to use LuaSQL only for configuration purposes. 

Greetings

Peter</description>
		<content:encoded><![CDATA[<p>Jan, Kay, thanks for your comments.</p>
<p>First of all, my assumptions MySQL Proxy is putting the whole result on LUA stack at once is false, indeed. I corrected that.</p>
<p>I reproduced the tests above on an 8-core-server with 8GB RAM putting the database on another server and using HEAP tables. Then the performance of both MySQL Proxy and LuaSQL was nearly equal, MySQL Proxy being about 2-5% faster. I was not able to see a performance gap of factor 1.6 - perhaps your &#8220;internal&#8221; 0.7 version has some other improvements? BTW: When is it going to be in SVN?</p>
<p>Kay, thanks for the pointer to LuaSQL + MySQL Proxy issues in high concurrency. I quickly tried to verify that by using &#8220;-c 10&#8243; switch in mysqlslap. But I could not see a drop in the LuaSQL performance. </p>
<p>As said above, I am planning to use LuaSQL only for configuration purposes. </p>
<p>Greetings</p>
<p>Peter</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kay Roepke</title>
		<link>http://pero.blogs.aprilmayjune.org/2008/09/07/luasql-fetches-results-about-15-faster-than-mysql-proxy/#comment-5264</link>
		<dc:creator>Kay Roepke</dc:creator>
		<pubDate>Tue, 09 Sep 2008 11:17:26 +0000</pubDate>
		<guid>http://pero.blogs.aprilmayjune.org/2008/09/07/luasql-fetches-results-about-15-faster-than-mysql-proxy/#comment-5264</guid>
		<description>I've tried to reproduce your findings, but wasn't able to.
In fact, for me the "plain" MySQL Proxy version was consistently about 1.6x faster (I have not profiled the code yet, so I can't currently say where most of the time was spent in each case).
For my simple test I've run everything locally on an 8-core box with 5.1.23rc and our internal proxy code (which for all intents and purposes is the 0.7.0 code in SVN).

As Jan already commented, only iterating the entire resultset will copy it onto the Lua stack, but either way the time necessary to copy it all in one piece or row by row should roughly be the same (of course there would be less function call overhead when copying it all at once, so that approach should actually be faster). It's all academic, though, because Proxy doesn't do it :)

My first suspicion was that LuaSQL would not buffer the resultset like Proxy currently does, but it does: It uses mysql_store_result() from the C client lib which buffers the entire response from the server. So that would have the same memory overhead as Proxy has. Without digging even deeper I'm really at a loss as to what causes the performance discrepancy you see.

Another comment on the use of LuaSQL here: In the face of higher concurrency this approach would severely limit the throughput, because the retrieval in read_query would block the connection. As such the Proxy couldn't serve other clients while it's waiting on the server response (because it doesn't go through the libevent handling, but opens a socket of its own).</description>
		<content:encoded><![CDATA[<p>I&#8217;ve tried to reproduce your findings, but wasn&#8217;t able to.<br />
In fact, for me the &#8220;plain&#8221; MySQL Proxy version was consistently about 1.6x faster (I have not profiled the code yet, so I can&#8217;t currently say where most of the time was spent in each case).<br />
For my simple test I&#8217;ve run everything locally on an 8-core box with 5.1.23rc and our internal proxy code (which for all intents and purposes is the 0.7.0 code in SVN).</p>
<p>As Jan already commented, only iterating the entire resultset will copy it onto the Lua stack, but either way the time necessary to copy it all in one piece or row by row should roughly be the same (of course there would be less function call overhead when copying it all at once, so that approach should actually be faster). It&#8217;s all academic, though, because Proxy doesn&#8217;t do it <img src='http://pero.blogs.aprilmayjune.org/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>My first suspicion was that LuaSQL would not buffer the resultset like Proxy currently does, but it does: It uses mysql_store_result() from the C client lib which buffers the entire response from the server. So that would have the same memory overhead as Proxy has. Without digging even deeper I&#8217;m really at a loss as to what causes the performance discrepancy you see.</p>
<p>Another comment on the use of LuaSQL here: In the face of higher concurrency this approach would severely limit the throughput, because the retrieval in read_query would block the connection. As such the Proxy couldn&#8217;t serve other clients while it&#8217;s waiting on the server response (because it doesn&#8217;t go through the libevent handling, but opens a socket of its own).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jan Kneschke</title>
		<link>http://pero.blogs.aprilmayjune.org/2008/09/07/luasql-fetches-results-about-15-faster-than-mysql-proxy/#comment-5219</link>
		<dc:creator>Jan Kneschke</dc:creator>
		<pubDate>Mon, 08 Sep 2008 16:11:00 +0000</pubDate>
		<guid>http://pero.blogs.aprilmayjune.org/2008/09/07/luasql-fetches-results-about-15-faster-than-mysql-proxy/#comment-5219</guid>
		<description>How many boxes are involved in this benchmark ? Is it all on one box ?

The proxy does only provide iterator to the result-set and the rows are converted one by one to lua if the iterator is called. What did gave you the impression it is covered to LUA completely ?</description>
		<content:encoded><![CDATA[<p>How many boxes are involved in this benchmark ? Is it all on one box ?</p>
<p>The proxy does only provide iterator to the result-set and the rows are converted one by one to lua if the iterator is called. What did gave you the impression it is covered to LUA completely ?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
