Firstly, sorry about misspelling your name. I was still half asleep, but that's no excuse. My bad.
We aren't getting switched up sessions. It's more like user A hits server 1, then bounces to server 2, but server 2 doesn't know how to retrieve the session for user A correctly. Thanks for the link and info on patch levels. I haven't checked into that yet, so I will. Regards, Ryan Riley From: [email protected] [mailto:[email protected]] On Behalf Of Shawn Neal Sent: Saturday, April 23, 2011 8:33 AM To: [email protected] Subject: Re: Network Load Balance Testing What do you mean by, "wrong session information?" Does that mean user A sometimes gets the session data for user B, or user A has 2 unique sessions? Session state is only dependent upon the session cookie and not source IPs. One issue you can have in a web farm is if they have different .NET patch levels, specifically this hotfix: http://support.microsoft.com/kb/2416472. It changes how .NET decrypts view state and session cookies amongst other things. If you have two servers in a farm, one with and one without the patch, you'll have all kinds of problems... even if they have the same machine keys. On Sat, Apr 23, 2011 at 8:05 AM, Ryan Riley <[email protected]> wrote: Thanks for your response, Sean. We are using Microsoft NLB, and we have a few scenarios where reverse proxies cause our customers HTTP and HTTPS traffic to come from different IP addresses. We are using SQL Server Session storage on a shared database server, and our machine keys are the same on both of our NLB web servers. However, we've watched what appear to be valid requests not pull in the correct session information when the user session hops between our servers. I'm trying to figure out how I can reproduce this locally so that I can isolate and resolve the problem in our web app, NLB cluster, or whatever else is actually causing the problem. Thanks! Ryan From: [email protected] [mailto:[email protected]] On Behalf Of Shawn Neal Sent: Friday, April 22, 2011 6:34 PM To: [email protected] Subject: Re: Network Load Balance Testing Are you trying to determine the overhead of having to renegotiate SSL when switching between https and http and/or between https requests? Are you specifically talking about Windows NLB? There's definitely overhead if you have to renegotiate a SSL session between each request if the load balancer sends you to a different server every time. I'm not sure how/if Windows NLB handles this. When we were testing SSL re-negotiate overhead we ended up doing this in our performance lab with Load Runner. We basically compared ART and CPU of load balanced http, https, and https with sticky sessions (didn't try SSL term at the VIP). We ended up using SSL with sticky sessions because we were able to use commodity hardware using layer 4 routing via HA-Proxy rather than dealing with the overhead of layer 7 or an expensive hardware load balancer. Good luck! -Shawn On Fri, Apr 22, 2011 at 4:43 PM, Ryan Riley <[email protected]> wrote: Any recommendations on testing a NLB environment? In particular, I'm trying to find a way to explore the impact in our environment of bouncing between our NLB servers, especially when switching between HTTP and HTTPS. Any thoughts are appreciated. I'm having a hard time tracking anything down on this one. Cheers! Ryan Riley Email: [email protected] LinkedIn: http://www.linkedin.com/in/ryanriley Blog: http://wizardsofsmart.net/ Website: http://panesofglass.org/ -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected] <mailto:altnetseattle%[email protected]> . For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en. -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en. -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected] <mailto:altnetseattle%[email protected]> . For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en. -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en. -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.
