From owner-freebsd-hackers Wed Jun 20 0: 4:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 54A0E37B403 for ; Wed, 20 Jun 2001 00:04:24 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f5K74M706441; Wed, 20 Jun 2001 00:04:22 -0700 (PDT) (envelope-from dillon) Date: Wed, 20 Jun 2001 00:04:22 -0700 (PDT) From: Matt Dillon Message-Id: <200106200704.f5K74M706441@earth.backplane.com> To: "Ashutosh S. Rajekar" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: max kernel memory References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :On Tue, 19 Jun 2001, Matt Dillon wrote: : :> to handle more then 250 requests/sec. With the connection load you :> want to handle, the chance of the data being cacheable in ram is :> fairly low. So a disk-based caching proxy will drop connection :> performance by two orders of magnitude. : :You are right, disk caching is only a backup plan; we really won't be :comfortable with it. :Also, the idea behind all this is that you free webservers from doing :painful TCP/IP stuff, and make it just handle content related stuff, thus :your proxy boxes will act like surge protectors/shock absorbers, etc. Yes, that works fairly well. Our mail proxies were particularly effective as surge protectors, preventing spikes from interfering with the shell machines. The web proxies primary job were to direct connections to the correct web server, but they also buffered data for hung or slow connections which greatly reduced TCP buffer space requirements on the web servers, freeing memory resources for other uses. :... :webservers). The real fun is very likely to be in TCP/IP tuning. I mean :the idea is to allocate very minimal memory for connections that have just :come in, and only when the proxy is likely to accept the connection is the :connection upgraded to a full-fledged one. This would possibly take care :of the million connections business. This is fairly easy to do. You can use SO_SNDBUF and SO_RCVBUF socket opts to adjust the tcp buffer space. You can make the default small and receive-centric and when you think you've got a good connection you can pump it up. I used fixed assymetric TCP buffering at BEST - I made the send buffer a lot bigger then the receive buffer. Or, more to the point, I left the send buffer pretty much alone and made the receive buffer smaller. :But going by the amount of customization required to be done before :FreeBSD can be used as a server OS, how about starting an independant :volunteer effort that would go into the details about providing a really :heavy-duty FreeBSD server ? Normal distributions may continue to :provide time-sharing type of functionality, but the people who want to :deploy FreeBSD in stressful environments would surely not hesitate to :throw in the money to buy machines with 4Gigs (even 64) of memory, :high-end processors and lotsa L2 cache, blah blah blah. Optimizations :could be of categories like: webserver, fileserver, netserver, IRC server, :FTP server, SMTP server, etc. Each of them would deal with details :involved with each protocol, and provide a server suited exactly to that :protocol. (Even a hybrid one is thinkable). : :Suggestions/flames are cordially invited. : :-ASR Well, that would be a book. A big book! Each configuration would be different, depending on the task. And topologies would be different too. For example, A web proxy would need a lot of descriptors and network resources, horse power, and memory, while a mail relay would require high performance disks but could get away with less horsepower and network resources (and less cpu too). A web proxy could be round-robined fairly easily, but for a mail relay it is often a good idea to split the incoming and outgoing mail into two separate round robins (two separate groups of machines). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message