dbTalk Databases Forums  

Re: Question about the level of compression used

mailing.database.mysql-internals mailing.database.mysql-internals


Discuss Re: Question about the level of compression used in the mailing.database.mysql-internals forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
AT
 
Posts: n/a

Default Re: Question about the level of compression used - 05-08-2006 , 12:40 AM






--=-Fj5zqeSdBR6wlqxzV9bC
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2006-05-05 at 20:50 -0700, Mark Callaghan wrote:
Quote:
OK. I will provide a patch soon. I will try to provide something that=20
has a global default and can be changed at the session level.
great!

Quote:
The current compression code allocates two buffers using free/malloc=20
that are each about as large as the uncompressed packet each time a=20
packet must be written to the network. I had another change that reduced=20
that to one call to malloc and free. That change did not have much of an=20
effect on performance, but I did not run any multi-threaded tests where=20
calls to malloc and free might be more expensive. I don't know how good=20
glibc malloc is for threaded apps. I do know that other mallocs are not=20
so good (Sun has published a paper on the benefits of mtmalloc for MySql)=
..

maybe try some benchmarks with mysqlslap or mysql-bench and see if you
can get it to be faster. Also, memory savings are always a good thing (i
don't know if your patch saves any memory though).

Quote:
From my limited understanding of MySql source, it tries to reduce the=20
number of calls to free and malloc, but the implementation of network=20
compression might be one case where that is not true.
As a general rule, the less calls the better. But simplicity also has
its place (easier to get something simple correct).

Quote:
Is it worth my time to try to prepare a patch that either reduces the=20
calls to malloc and free to one per flush of a packet to the network=20
rather than two calls as is currently done? The calls could be further=20
reduced by caching the allocated buffer as part of the thread context so=20
that it is only allocated once.
possibly... some benchmarking to see if it's of any benefit to do so
would be interesting. Somebody with more knowledge of that area of code
could give some input that could be just as useful as the benchmark.

--=20
Stewart Smith, Software Engineer
MySQL AB, www.mysql.com
Office: +14082136540 Ext: 6616
VoIP: 6616 (AT) sip (DOT) us.mysql.com
Mobile: +61 4 3 8844 332

Jumpstart your cluster:
http://www.mysql.com/consulting/packaged/cluster.html

--=-Fj5zqeSdBR6wlqxzV9bC
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBEXtm4KglWCUL+FDoRAoesAKCcRpuc+U8pT4W1PHZzK/sZHeie2gCcCp/N
OtEw8jVIOs8YIHpljsePE3A=
=L1Rs
-----END PGP SIGNATURE-----

--=-Fj5zqeSdBR6wlqxzV9bC--



Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.