Date: Thu, 12 Jul 2001 21:20:47 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: Leo Bicknell <bicknell@ufp.org>, <hackers@FreeBSD.ORG> Subject: Re: Network performance tuning. Message-ID: <20010712211647.I21859-100000@achilles.silby.com> In-Reply-To: <200107130128.f6D1SFE59148@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 12 Jul 2001, Matt Dillon wrote: > This is fairly easy to do for the transmit side of things and would > yield an immediate improvement in available mbuf space. For the receive > side of things we can't really do anything with existing connections > (because we've already advertised that the space is available to the > remote end), but we can certainly reduce the buffer space we reserve > for new connections. If the system is handling a large number of > connections then this sort of scaling will work fairly well due to > attrition. > > We can do all of this without ripping out the pre-allocation of > buffer space. I.E. forget trying to do something fancy like > swapping out buffers or virtualizing buffers or advertising more > then we actually have etc etc etc. Think of it more in terms of > the system internally sysctl'ing down the send and receive buffer > space defaults in a dynamic fashion and doing other reclamation to > speed it along. Buffer space isn't really preallocated, so no work needs to be done there, as you state. The trick is auto-changing the size *correctly*. If we bump the default up to 64K, apache will fill each socket with 64K of data, no matter the speed of the box requesting the file. So, we have to start small by default and scale up as the connection goes on. The criteria to use when sclaing up is what would require the most work in making the buffer space used dynamic. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010712211647.I21859-100000>