Forum Discussion
Ray_Dodier_1102
Nimbostratus
NimbostratusSSL connect time diffs between domains (VIPs)
I serve HTTPS content from two different domains and each domain name corresponds to a VIP. What I'm seeing is the SSL connect time from one domain is about twice that of the other domain.
Not sure if this matters, but the VIP corresponding to the domain with the faster SSL connect time is using an iRule filter to get to the static content pool. The VIP with the slower SSL time has no rule and just goes directly to a different static content pool. I tried making the slower one go through a rule instead of dir4ectly to the pool but saw no difference.
I'm not finding anything obvious as to why one domain (both are in the same subnet) is performing so differently than the other. My limited understanding of this is that the SSL time is strictly between the client's browser and the F5. If so, there should be no difference, but there is. Can anyone think of what might be causing this performance difference?
5 Replies
HamishCirrocumulus
Could be lots of things... What I'd suggest is you break it down and look at each portion of the connection individually.
e.g.
1. The SSL connection. Use CURL or openssl to create a connection and make a request while using tcpdump to save the traffic for that connection (Use a suitable filter). Then have a look with wireshark, (Or tcpdump again if you're confirmable with that) to determine if there's a big difference in the SSL negotiation between the two VS's
2. Using HTTPWatch, or firebug or something similar have a look to see if it's the connection time or request time that's making a difference between the two.
3. tcpdump the backend traffic. Perhaps the backend static pools are the problem. Do they both respond in the same time?
H
Ray_Dodier_1102So here's the deal. The VIP with the longer SSL time is not doing the SSL handshake correctly at least half the time.
The Server Hello response from the F5 is coming back with 1 of 2 Session IDs. Every other time there is an SSL handshake to this VIP it has to do a full-handshake because the Session ID sent in the Client Hello request does not match what's coming back from the F5. The Client Hello always uses the same Session ID.
This means it's having to do a full-hanshake every other time to one VIP. I do not see this behavior with the other VIP.- Ray_Dodier_1102
More info on this -
The tcpdump on the F5 is not showing Server Hello responses. What I see when I look at this with WireShark is [Packet size limited during capture] where I would have expected to see the Server Hello response. This truncates the SSL response that I suspect is the Server Hello.
What got me here in the first place is that we have a network appliance called a Coradiant that captures HTTP traffic. Reports from this were indicating a problem with long SSL latency times on content from one of the VIPs. I tracked this down to a filter that was excluding most of the initial data object loads from the VIP with less SSL latency. This is where the SSL connections to this VIP would be made so the Coradiant was filtering out the traffic where most of the SSL time would be incured for one of the VIPs.
Once I modified the filter to save all content a comparison showed similar SSL latency between VIPs but one VIP was still slightly slower. The SSL latency differences are now down to the fact that one of the 2 VIPs is not doing the SSL handshake as efficiently as the other, and I have no idea why this is happening. - Ray_Dodier_1102So is there anyone who knows why the F5 would alternate between 1 of 2 sessionIDs in the Server Hello response in the SSL handshake for every connection? I tried disabling one of the 2 servers in the static content pool in the event it was somehow using that to build the sessionID but I still get the same thing.
hoolioCirrostratus
Considering how you've isolated the performance issue to SSL session re-use, I'd suggest opening a case with F5 Support. They should be able to review your full config and binary tcpdumps to help you resolve the issue. We could give you hints and tips, but the support route would probably be a lot quicker as they'll be able to inspect the full data.
Aaron
