Sergey S. Levin wrote:
1. If i use FileZilla and SSL connection - it works on 100% of speed.
I dont know what FileZilla is, but which SSL implementations is used and
what key exchange protocol and what symmetric cipher did it choose ?
2. The processor load is just 5% so, this should not be the crypto problem.
Hey you are only transfering 30Mb, increase this to something that make
the test take 10 minutes or more then come back to tell us what the
processor load is at each end.
This might also be a good test to highlight if the problem is with the
application and not something more fundamental with the TCPIP and
Ethernet layers. If you can't get your app to give you 100% load on at
least one end then maybe you need to get tcpdump out. If you can then
it highlights which end is having a performance problem at application
level.
Maybe the others are right in questioning:
BIO_ctrl(out, BIO_CTRL_FLUSH, 0, NULL)
The next BIO_write() will automatically flush the preceeding application
data.
If you want to flush do one at the end of the for(;;) loop, as I cant
see any code to call SSL_shutdown(ssl) I would not even be sure the last
plaintext bytes actually reached the other end before the application
terminated, I'd recommend you insert after the for(;;) loop:
BIO_ctrl(out, BIO_CTRL_FLUSH, 0, NULL);
SSL_shutdown(ssl);
SSL_shutdown(ssl);
The two SSL_shutdown() cause the shutdown notify to be emitted to the
far end and the 2nd one will enforce a flush and wait.
> http://www.bw-team.com/openssl.PNG
I have taken a look at your graph but I still go with my suggestions to
provide a table of timing information as requested before.
Also as others have suggested find out which cipher is being used and
run the benchmarks on the systems at each end: openssl speed aes-256-cbc
aes-128-cbc des-ede3 rc4
The API calls to dump this out are documented "man SSL_get_cipher" but
you need to call these anytime after the 1st BIO_write() call is made in
the app, this would be the point in time after the initial handshake has
completed.
> Does this mean that the OpenSSL lib each BIO_write makes the handshake?
No, but at setup the initial handshake is mandatory and its a 5 way
affair, the cost in time is at least "2 * round-trip-time" plus the CPU
wall clock costs for computing PKC in the key exchange. It is the key
exchange that can be slow (especially under my original guess that you
were only transfering 3Mb of application data, in that hypothetical
scenario I would expect PKC cost to be higher than bulk encryption cost
for 3Mb of data).
But to be clear about your performance claims:
You are claiming other SSL client implementations are faster, and if I
understand correctly you are using the same SSL server implementation to
test against on exactly the same hardware setup both ends to compare
(i.e. nothing was changed on the client side except the client
applicaiton being used) ?
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
