From: Michael Widenius Date: March 30 1999 10:07am Subject: Linux Threads and socket options List-Archive: http://lists.mysql.com/mysql/1175 Message-Id: <14080.40918.293361.424996@monty.pp.sci.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >>>>> "Chris" == Chris Wilson 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