I'd get some more diagnostic info if I were you. Ramp up your logging level in your AT-TLS configuration and also take some network packet traces. There may be multiple SSL handshakes taking place in pseudo-conversational mode but in traces I have taken (of TN3270 connections) the SSL overhead (in terms of elapsed time) is only a few milliseconds anyway. You need to figure out the biggest contributor to your 10 second response times.
BTW, we don't use any crypto hardware so I have configured AT-TLS to use the z10 CP Assist for Cryptographic Function (CPACF) support - you need to enable it using the HMC first. This enables instructions for computing SHA hashes and some other stuff. To do that, all I did was to disable any cipherspec that doesn't have a _SHA suffix. This should result in CPACF machine instructions being used instead of having to call a routine to compute SHA hashes. It might not be a big difference, but worth a try. Also, even if you did have a crypto card I don't think you'd see any real benefit until you were doing 100's of SSL handshakes a second anyway. To rule out encryption overhead, try (temporarily) using cipherspec NULL_NULL_SHA (from memory...I haven't checked the actual name) so that encryption doesn't occur on your SSL connections. You can't blame SSL overhead if there is no encryption taking place! Cheers, Andrew. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
