Load estimation - SSH on HP-UX

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
   Hello everyone,
We are looking for a high-performance SSH solution for HP-UX platform.
The idea is to protect an existing application, so the server should
perform port forwarding only.

 A couple of requirements:
1) Should run on HP-UX B.11.11 U 9000/800
2) Hardware configuration - 1 HP server with 8CPUs 16GB RAM
3) We need to support up to 1000 concurrent connections (open tunnels).
4) The upper limit expected connection growth - 50 / minute (let's say,
1 new connection per second).

  OK, now the questions:
1) Do you think it is applicable? Can such hardware handle such
CPU-intensive requirements?
2) If so, will it work with OpenSSH or a commercial solution will be
required (maybe Tectia - please recommend)?

3) In case of OpenSSH:
 a. Do you recommend compiling for 64 bit, or just use 32bit?
 b. Is sshd optimized to run on several CPUs?
 c. Is there any way to tune number of processes / threads etc, in
order to optimize the performance?

Thanks a lot in advance,

Re: Load estimation - SSH on HP-UX

Quoted text here. Click to load it

Probably yes, it depends on how you intend it to work.  The answers
depend on whether or not you intend to:

A) Run one SSH session per forwarded connection.

B) One a single SSH session with a large number of forwarded connections.

The remainder of this post is specific to OpenSSH and may or may not apply
to other software.

Either way, allowing only port-forwarding is simple: set the account's
shell to be, eg /bin/true and add it to /etc/shells, then use the ssh -N
option (or its equivalent) on the client.  The clients will be able to
authenticate and forward ports, but not run anything (other than "true"
:-) on the server.

For A), the limiting factor is likely to be memory consumed by the sshd
processes (there will be two sshd's per connection if privsep is enabled,
one per connection otherwise) and the speed at which connections (SSH
handshake) can be performed.

With my old C-class (236MHz) as a server, I can establish a single SSHv2
connection in about 0.8 sec and could probably reduce that by 20-30%
with a bit of tuning, so 1 per second is probably within easy reach of
your hardware.  The sshd processes have a resident size of around 600KB
each (as shown by "top").

For B), the limiting factors are probably going to be:
 B1) There's a sanity-check limit of the number of port forwards of 100
     per direction.  (look in ssh.h for SSH_MAX_FORWARDS_PER_DIRECTION,
     you can bump this at compile time).
 B2) Per-process descriptor limits (probably just need to bump "nofiles"
     with ulimit).

It is very unlikely that symmetric encryption speed is going to be a
limiting factor.  The aforementioned C-class can do 128-bit AES at
8 MBytes/sec and arcfour at 27 MBytes/sec.  (That's raw speed from
"openssl speed", throughput in ssh will be lower, but I can still push
4 MByte/s onto /dev/null on my C-class over the wire with 128-bit AES.)

Quoted text here. Click to load it

I'm biased so I won't make a recommendation.

Quoted text here. Click to load it

32bit, possibly tuning the compiler options on OpenSSL, zlib and OpenSSH
to suit your system.  I would also make sure you have a good entropy
source (a real /dev/random device if you can get one, otherwise prngd).

Quoted text here. Click to load it

In the case of A) above, yes.  There will be multiple sshd's and they
may be scheduled to run on as many CPUs as your system has.  In the case
of B), no, there will be only a single process and no threads (but it's
not likely to matter, see above).

Quoted text here. Click to load it

For threads/processes, no, not really.  For other things there's some
hints here: http://www.openssh.com/faq.html#3.3
There may be other tuning things that can be done to suit your

Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Site Timeline