concurrent scp transfers (and a testing methodology ?)

[Louis A. Mamakos]

> 
> I have read several documents on the number of
> concurrent  https sessions a FreeBSD system is capable
> of.
> 
> However, I wonder how well this relates to how many
> ssh sessions (scp file transfers, specifically) that a
> FreeBSD server can handle.  Can anyone throw out some
> basic numbers for this ?  Assuming a 1ghz p3 and 2gigs
> of RAM, and assuming that everyone is transferring a
> totally different file.  (so there is no amount of
> cache hits - everything comes straight off the drives)
> 
> I would think the major bottleneck would be disk - you
> would start chugging the disks far before you used up
> all the CPU on a 1ghz p3 ... but what is the second
> bottleneck ?  Is it cpu, or is it ram (or mbufs, etc.)
> 
> Would it be a reasonable test to just start up scp
> sessions from the machine to itself and then divide
> the number of sessions you can acceptably create by
> the number 2 ?  Or is this somehow a flawed test ?
> 
> Any additional comments (kernel tunes, settings, war
> stories) are greatly appreciated. (like, does SMP help
> a lot here, or just a little ?)

What crypto algorithm are you using for your ssh/scp
session? AES, DES, 3DES, arcfour?  Any hardware assist for
doing the crypto?  Are you having the underlying SSH session
try to compress the data?  

louie