Date: Tue, 06 Jul 2004 10:01:13 -0400 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Joe Schmoe <non_secure@yahoo.com> Cc: freebsd-hackers@freebsd.org Subject: Re: concurrent scp transfers (and a testing methodology ?) Message-ID: <20040706140113.4DE6D20F83@whizzo.transsys.com> In-Reply-To: Your message of "Mon, 05 Jul 2004 13:51:00 PDT." <20040705205100.88989.qmail@web53307.mail.yahoo.com> References: <20040705205100.88989.qmail@web53307.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040706140113.4DE6D20F83>