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]. > 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. > -- 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.
