>>>>> "Chris" == Chris Wilson <cmw32@stripped> writes:
Chris> Hi,
Chris> I don't really know who to ask on this one, because mysql is unsupported
Chris> (obviously, as free software), but maybe someone on this list can tell me,
Chris> or at least point me in the right direction.
Hi!
I first want to clear up one thing; MySQL is not unsupported !
TCX provides commerical support to MySQL.
You can find information about the MySQL license prices and the MySQL
support levels at
http://www.tcx.se:/Manual_chapter/manual_Licensing_and_Support.html
MySQL is also only free for inhouse use;
The very reasonable license and the fact that is distributed in source
makes it easy to regard MySQL as free software, even if MySQL is a
commercial product.
Chris> MySQL has the option to set TCP_NODELAY on the server's listening socket,
Chris> however, this is only compiled in on FreeBSD:
Chris> #if defined(IPTOS_THROUGHPUT) && !defined(HAVE_LINUXTHREADS) /* For
Chris> FreeBSD */
Chris> if (fd > 0)
Chris> {
Chris> #ifndef __EMX__
Chris> int tos = IPTOS_THROUGHPUT;
Chris> if (!setsockopt(fd, IPPROTO_IP, IP_TOS, (void*) &tos, sizeof(tos)))
Chris> #endif
Chris> {
Chris> int nodelay = 1;
Chris> if (setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, (void*) &nodelay,
Chris> sizeof(nodelay)))
Chris> {
Chris> DBUG_PRINT("warning",("Couldn't set socket option for fast
Chris> send"));
Chris> }
Chris> }
Chris> }
Chris> #endif
Chris> This appears to be deliberately excluding the use of TCP_NODELAY on Linux
Chris> (presumably because of the Linux Threads package). What I want to know is,
Chris> whether there is a really good reason for NOT using TCP_NODELAY on Linux?
Chris> I have a strong suspicion that we are suffering severe performance hits at
Chris> our site because of this option.
On Linux, I was on the assumtion that the use of NONBLOCK send/recieve
should be enough; We haven't however timed what happens if one enables the
above code for Linux...
Chris> I think this because running a query and sending the results to /dev/null
Chris> or a file takes 1.4 seconds. Sending the same query over the network
Chris> (100MBps) takes about 30 seconds and runs at 50k/s. tcpdump shows that
Chris> each packet sent by the server is immediately followed by an
Chris> acknowledgement (i.e. the server waits for acknowledgement before sending
Chris> another packet). TCP_NODELAY would seem to prevent this.
Chris> In any case I am about to remove the !defined(HAVE_LINUXTHREADS) condition
Chris> and run comparison benchmarks on the system (hopefully the benchmarks will
Chris> also pick up any possible data corruption). If anyone suspects that this
Chris> will cause data corruption, please could you let me know immediately
Chris> before I destroy all our company's data :-)
I think that removing the above test should be safe; The MySQL protocol will
automaticly detect missing packets so it should notice if something
goes fatally wrong! As all SQL commands are sent as clear text, it's
very unlikely that you will corrupt any data!
You can also try running the client with --compression; The
uncompress code should detect any corruption in the real data!
Regards,
Monty
