From owner-freebsd-hackers Tue Dec 2 01:05:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA13607 for hackers-outgoing; Tue, 2 Dec 1997 01:05:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dns (dns.ida.net [204.228.203.1]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id BAA13599 for ; Tue, 2 Dec 1997 01:05:46 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (tc-if2-10.ida.net [208.141.171.67]) by dns (SMI-8.6/mail.byaddr) with SMTP id CAA13733 for ; Tue, 2 Dec 1997 02:00:17 -0700 Date: Tue, 2 Dec 1997 02:05:39 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: hackers@FreeBSD.ORG Subject: Re: ftp server on ftp.cdrom.com In-Reply-To: <199712020834.AAA15970@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> On Mon, 1 Dec 1997, Amancio Hasty Jr wrote: > >You can do it as you have suggested also the thing to keep in mind is the > >cost of per connection and memory. For instance a process context switch > >plus the over head of a process is not a very efficient mechanism for > >large scale ftp servers. > > Oh? Are you speaking as an authority on this subject? :-) Actually, > context switch overhead is not a problem. Processes in FreeBSD are fairly > light weight in terms of memory as well and most of the memory is consumed > by socket and disk buffers, not by the overhead of a process (at least in > my implementation of ftpd). > Anyway, I don't mean to squelch the conversation regarding this, but > I do ask that people not make silly assumptions without first actually > studying the problem. > > -DG No aspersions were intended towards your ftpd, at least on my earlier posting to which you did not directly reply. I was just thinking aloud about Amancio's suggestion and none too precisely at that. I've just gone through an effort of monitoring and herding PIDs for a specialized type of server, and it was none too pleasant I can tell you. I was intrigued by your use of shmctl(), which seemed quite clever to me. Shared memory and advisory locking are a big nuisance to deal with when trying to make software cleanly compile across different platforms and kernel configurations. Threading eliminates the need for these things but also creates other headaches. For moderate numbers of open sockets (50 to 100), a synchronous state machine with non-blocking I/O doesn't sound that bad for some of my modest needs (far smaller than the Mt. Everest of wcarchive). >From your standpoint, would there be performance advantages to 50 processes each handling 50 connections vs. 2500 processes? Or as you say, are sockets and disk I/O the primary thing? Charles Mott