Date: Wed, 20 Jun 2001 00:04:22 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: "Ashutosh S. Rajekar" <asr@softhome.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: max kernel memory Message-ID: <200106200704.f5K74M706441@earth.backplane.com> References: <Pine.LNX.4.21.0106201112090.1235-100000@vangogh.indranetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106200704.f5K74M706441>