SSH Reference Manual

Performance Analysis of SSH Session
Establishment
Performance Running as SSH Daemon
The performance impact of the initial SSH session setup should be viewed separately. As explained before, establishing
an SSH session involves several CPU-intensive public key operations. The amount of CPU cycles consumed depends
upon the key sizes used.
The following table shows the CPU consumption of an SSH session setup (without any data transfer taking place) for a
DSA host key with 1024 bit length and for RSA client keys with the sizes as stated in the table:
Client Key size [bits] Approximate CPU consumption [milliseconds]
512 234
1024 236
2048 242
It is very hard to predict future developments, both in cryptography and computer technology, which makes it next to
impossible to tell in advance what key size will be sufficient in the years to come. We recommend using a key size of
1024 bits for the time being.
Performance Analysis of SFTP Traffic
To get an indication of the performance of the SSH2 component and the subordinate SFTPSERV processes when acting
as SFTP daemon, the average transfer rate and CPU consumption has been measured while a file with 50 MB of data has
been transferred via SFTP.
The following table shows the result of the measurement:
Partner
system
Direction of
transfer
Cipher
Suite/MAC
algorithm
Time
elapsed [s]
CPU time
used [s]
Through-put
[KB/s]
CPU ms/MB
transfer
CPU usage
Linux,
OpenSSH
NonStop to
Partner
system
AES-
128/MD5
66,5 27,1 734 568 41 %
Linux,
OpenSSH
Partner
system to
NonStop
AES-
128/MD5
242 26,6 202 557 11%
Please bear in mind that the measured transfer rate does not only depend on the performance of the SSH2/SFTPSERV
components, but also on the network throughput and the performance of the remote SFTP client or server.
The most significant column of the table probably is the value "CPU ms/MB transfer" which should give a good estimate
for the CPU milliseconds needed to transfer one Megabyte of data using SFTP.
SFTPSERV Performance of ls Command with Wildcards
The output from command ls (list) can be delayed when wildcards are used and the file information returned by
SFTPSERV is not processed effectively. Unlike the ftp protocol the sftp protocol does not define two commands for
listing the names of files in a directory (ftp: NLST) and listing of all file attributes of files in a directory (ftp: LIST).
There is only one command in the sftp protocol (READDIR) that always retrieves all attributes of the files in a directory.
In case of a wildcard (e.g. ls test*) the SFTP client will do the pattern matching after all file attributes have been
retrieved from the SFTP server. After the pattern matching the SFTP client could display the file listing but there are
328 • Performance Considerations HP NonStop SSH Reference Manual