Another possibility is the client is not sending the session cookie. I would check the cookie domain on the client, if each server in your farm issues a cookie with a host specific domain that would explain the behavior you are seeing. You might need to set a common cookie domain in the web.config.
On Apr 23, 2011, at 10:44 AM, "Ryan Riley" <[email protected]> wrote: > 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]. > 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. > > -- > 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.
