At 04:39 PM 10/14/2003, Chris Merrill wrote: .....
One way that we test our HTTP/SSL performance is by driving a browser through a proxy server that we have implemented in Java and the Sun SSL implementation. When we browse directly to the webserver (without the proxy) in IE our large test page takes ~2 seconds to load. When we run through our proxy implementation, it takes ~12 seconds.
One possibility is that Java is doing reverse name lookups on the ip of the requestor. This can add huge delays if the reverse lookup does not resolve. There are ways around that if that is the case. I do not know whether that might actually apply or not in your particular case though....
I have to second this suggestion. I've done a lot of work with SSL in past projects at work and I'm surprised at the degradation numbers you are seeing. While SSL does add significantly to the latency of a request, it should not be adding 10 seconds to the time it takes to load a 2 or 3 second page. I'd recommend hooking up some sort of java performance profiler on your server side and try to get an understanding of what hunks of code are being executed during that 10 seconds.
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?
--Calvin Powers
_______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
