Subject: Re: Scalability questions

From: DJ <[email-masked]>
Date: Fri, 25 Sep 1998 17:23:51 -0700

John,

Our commercial secure FTP software has been load tested to 1000 simultaneous
users.  This was a two processor Ultrasparc with 512Mb RAM.

The biggest issue is RAM.  You do not want to be paging, or you will
die.  There must be enough RAM to hold ALL active processes in memory.

We also found that startup time was a big issue.  That is why we made
our servers have a "standalone" mode so that you do not have to reread
config files at each new login.

We have also done performance measurement on SGI IRIS servers.

We do run on FreeBSD and Linux, but have not tested beyond 200 simultaneous
on those platforms.

Another big problem you may face in such an environment is the reuse
of sockets.  Especially on Solaris you will find that the OS does not
release sockets for about 3 minutes after the program ends.  This can
cause big problems when handling lots of small transfers with lots of
logins.  Doing directory listings hurts big time, as they fork off new
sockets for the data connection back to the client.

For 1000 simultaneous users you want to run in standalone mode.
Forking off from INETD is really going to kill your performance.

It is pretty easy to do the math to figure out how much bandwidth you need
for a given throughput for a specified number of users.

For example, we have shown that you can support 1000 users over a 1
hour period uploading a 2Mb file each  on a T1 line.  We have done
this mathematically and, more importantly, we have actually done
it in practice.

If you have any interest in a commercial FTP server, please see
us at www.differential.com.   I would also be happy to answer other
questions you have regarding doing this with the freeware WUFTPD.

Best of luck.

David Jevans

At 05:49 PM 9/22/98 -0700, John Olp wrote:
>Sorry folks if this gets too much off-topic, but I can't seem to find the
>answers, 'though I know they're out there.
>
>I need to scale up to 1000 or more simultaneous ftp users and could use
>some insight with regard to the following:
>
>1) I recall reading about problems where even though the ftpaccess file
>listed enough connections for certain class types, the limit that a server
>would actually permit was based on other things.  I also have seen the
>answers, but now I can't find them when I need them.  I believe one of them
>was a limit that was a descriptor limit or something of that sort compiled
>into the kernel, and another was some way of getting inetd to increase the
>number of allowed connection beyond some default.  Do these ring anybody's
>bell?  I also remember seeing something relating to a large number of users
>all trying to connect at once.  What kind of issues does that create?
>
>2) If anybody has already done the metrics, what kind of iron do I need to
>support this scenario (ie. memory, mhz)?  Has anybody done a benchmark
>comparison of wu-ftp on various platforms?  I'd like to stick with FreeBSD
>or Linux, but am open to other platforms if the performance is better.
>
>3) I don't know what our average file size will be yet, but I'm hoping we
>can get by with just a T-1 connection.  Does anybody have figures or
>signal-to-noise ratios for ftp data encapsulated in IP over a
>point-to-point T-1?  I'm not really concerned with latency on the Internet,
>I'm just interested in knowing what amount of raw data bandwidth I can
>sustain from a host connected to the Internet via T-1 (ftp server and
>router are on a 10Mb ethernet).
>
>Thanks for any help,
>
>John
>
>
>
>
>