On Tuesday, October 14, 2003, at 08:57 PM, Calvin Powers wrote:
Some misc things to check:
-- As Don indicated above, make sure that the SSL implementation is not trying to do a reverse DNS lookup on the browser's IP address.
-- Make sure that the SSL implementation is not trying to fetch the certificate authority's signer certificate used in the SSL transaction from a remoe location. This could be ocurring on the server side (if you are using client side certificates to authenticate the web browser). But it's more likely to be occurring on the browser side as the browser tries to verify the certificates that the server sends to it. If you are using an in-house certificate authority, instead of getting a certificate from a commercial service, you may need to import the in-house certificate authority's signing certificate into the browser's key ring. Otherwise, the browser may be trying to fetch the certificate authority signing certificate from a remote location.
-- Some browsers have an option to check "revocation lists" to ensure that the certificate used by the server side during the SSL negotiation has not been "revoked" by the issuing certificate authority. Make sure this is turned off in your browser.
-- if your server supports HTTP 1.1 protocols, make sure it's enabled. This can greatly reduce the "ssl handshake" overhead that occurs at the beginning of each TCP connection.
I'm just curious, which SSL implementation are you using? The one that comes with the JVM these days?
I implemented the system Chris was writing about, and please correct me if I'm wrong, but the above items would slow down the connection phase of an SSL connection, but not the data transfer phase. The way the page is fetched a single SSL connection is made from the client, and then all of the 99 images are downloaded over that single socket. It is for this reason I assumed that the performance problem was in the SSL decryption system. A profiler shows that all of the time is being spent in the JSSE classes, but I haven't taken the time to figure out exactly what part.
Michael,
You're right. All the things I listed above would cause unnatural delays during the connection phase of SSL. aka "the ssl handshake". I would still check the above items,just to make sure. And I'd double check to make sure that http 1.1 is infact being used (i.e., there really is only one TCP connection.)
I'm stretching a bit but here are some aditional ideas:
-- try to figure out the cipher specs that are being negotiated for the SSL encryption. Maybe they are using an unusually large key size for the bulk data encrytion. Most SSL apps I've seen just use RC4 as the bulk data encryption, which is about as fast a bulk encryption algorithm as there is. If your SSL encryption is using some other algorithm, that might explain the slowness.
-- make sure that the SSL connection is not renegotiating the encryption keys too often. During the encryption phase, I believe the two ends agree to renegotiate encryption keys every so often which adds over head to the SSL encryption. In the HTTP world, most connections are short enough that no one bothers to do this. But maybe it somehow got accidently turned on?
-- Make sure the SSL socket is using the underlying TCP socket effectively. I've seen cases where the SSL implementation read a single byte at a time off the underlying TCP connection instead of doing multi-byte reads to get all the buffered up data on the connection. So doing a gazillion sngle byte reads really slows things down.
-- Check the TCP connection options. Maybe the problem is in the TCP connection itself and not the SSL layer on top of it.
All of the above items would be pretty unusual. I would expect that the defaults in jsse would be set up to avoid all the problems listed above. You'd probably have to go out of your way to do stuff that causes the above problems. But still they are things to consider.
Beyond that, I'd say the thing to do is to dig into your profiler data to get the next level of detail in terms of which jsse classes are chewing up the CPU.
I'd be interested in hearing what you find out on this. I try to keep up with SSL issues.
_______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
