Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Dec 1997 02:05:39 -0700 (MST)
From:      Charles Mott <cmott@srv.net>
To:        hackers@FreeBSD.ORG
Subject:   Re: ftp server on ftp.cdrom.com 
Message-ID:  <Pine.BSF.3.96.971202013533.9777A-100000@darkstar.home>
In-Reply-To: <199712020834.AAA15970@implode.root.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971202013533.9777A-100000>