> ..I mentioned overhead not in terms of data bytes, but the time.
> Considering that in the system each session should not last not
> more than 3-4 seconds, and client wanting to make multiple SSL
> session with server, persistence can offer performance improvement.


You're just making that up, because you haven't measured. In fact, common
sense would suggest the reverse. Persistence requires each SSL session to
completely shut down before the next session can even begin building up.
Using a new TCP connection can allow the next SSL session to start setting
up as soon as the decision is made to end the previous one without having to
wait until the shutdown completes.

> Also each client that the application simulates would pick up a unique IP
> address, [ virtual address are configured in the system]. Each thread

would
> have a unique socket connection with server. These threads would be

working
> parallel in communicating the sevrer.
> Would there still be issues of TCP stream getting mixed up across threads

?

It's possible to make a mistake like this and also possible that you didn't
make a mistake like that. There's no way to know without looking at your
design. You do know that dedicated threads for connections is one of the
worst design patterns out there, giving you almost all of the disadvantages
of threads (overhead of synchronization, for example) with almost none of
the advantages (work can still get done even if a thread blocks for an
unexpected reason, fewer context switches, and so on).

DS


__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majordomo@openssl.org