I have a problem here.. i have site running on server A (with IIS7) and same site running on servers B (with IIS7).
Now if i goto my site from Server A and then goto the same site from Server B both the time i get the same the session id.
But when i got my sites set up on IIS6 i get different session ids no matter which iis6 server that i am going from .. which is desirable.
Is there some setting on IIS7 that i change or modify to get the same behavior?
It sounds like server A and server B have a common session state store, either IIS state server or SQL.
Related
I want to be able to deploy a new version of my asp.net/mvc website without loosing client session state or causing any downtime. The way I'm thinking of accomplishing this is by creating a Windows Network Load Balancing server so that clients can reach it via a single url such as https://mysite.org/. It would then redirect traffic to one of two other sites (A.mysite.org or B.mysite.org). I'll set the NLB's affinity to Single, and disable site B so that all sessions are are directed to site A. When I need to deploy a new version of the website, I'll deploy to site B, enable site B, and disable site A. So, everybody that was on site A can stay there (using version 1) until they log off. All new sessions will connect to site B and run version 2. The next time I deploy, I'll do the reverse.
I've never used NLB. Is this appropriate? Is there a simpler, easier way?
How does NLB know when a request from client X already has a session on A or B? Ie. when they log off the website, and try to login again, will the nlb send them to the same site they were on before?
There are quite a few considerations here
Firstly, rather than juggling the affinity on your NLB, you will probably be better storing your ASP.NET Sessions in StateServer or SQL based Session management to allow web clients (or web service clients) to access your site without 'sticky' affinity. Once you've set up the StateServer or created the SQL Session DB, it should be a simple change to your app's web config.
NLB itself works great for keeping your site up while you upgrade your site. You will typically drainstop a server in the cluster before reinstalling your app to it, test it, and then bring it back into the NLB cluster, before repeating the process with the next server etc.
AFAIK, NLB Single Affinity works at TCP/IP level and is does not interrogate ASP.NET sessions. Basically any connection from the same client IP to the same server IP:Port combination will be directed to the same server. Also AFAIK, both servers will be sharing the NLB IP (In addition to any existing IP's they have).
Since it seems your site uses SSL, it seems that unless you have affinity, that the SSL session keys will need to be renegotiated on each request, which could have performance implications.
I have 2 load balanced web servers. My application is using the SQL Server Session State database on SQL Server 2008.
The 2 web servers are identical in terms of IIS configuration, and if I understand correctly, the two web apps on the two servers will be mapped to the same app id in the ASPStateTempApplications table since they have the same IIS configuration. So, counting the number of sessions associated with this app Id (from the ASPStateTempSessions tabel) will result in the total count of sessions on the two web servers together.
My questions is:
Is there a way to know how many sessions are active on each server individually?
I have the problem that when I take one server out of the load balance, I want to know if there are still any active sessions on the server or not before recycling it.
Another scenario, if I have to recycle the IIS on one of the servers because another web app on the same server is crashing, I would like to know how many sessions will be affected when I do so.
Thanks.
Basically, they all may and actually SHOULD be active on both ) Because in this mode sessions are not bound to the web-servers at all.
You can stick each user to a single server with load-balancing techniques on your gateway and if so - better to use InProc mode with all its benefits )
Since the session data is stored in SQL Server, you shouldn't have to worry about how many sessions are active. Once the server is shutdown (or IIS is recycled, depending on the configuration), the load balancer will automatically send any new requests to the active IIS server. With the session data stored in SQL, the active server can retrieve the session data and the user will be unaware that any server switching has occured.
Ideally, you should test this procedure periodically to make sure everything is configured correctly. Also, you should follow this procedure when installing patches to the servers.
I am just making a demo application and want to configure asp.net to use webfarm. How can I do so?
I have already configured my session mode to use SQL Server and it works perfectly. What should I do next? I am using Windows 7, SQL Server 2008 and Asp.Net 4.0 webforms.
You need multiple machines - set up the application on both of them and configure both web sites to have a common host name/header. You also need to setup a common machine key for encrypting view-state etc. In real web farm setup, you will have a s/w or h/w load balancer that will be route requests to either server based on load. In case, you don't have a load balancer then use your local hosts file to resolve the common host name - for example, for first couple of request, use machine 1 and then switch it to machine 2 for next few and so on.
Our (reasonably busy) intranet web site has recently been sometimes taking 2-3 minutes to log in users on the production server, and we haven't been able to find why.
The web site is a "top-level" web site (mapped to an IP address) containing an additional 10 virtual directories. The web site contains both classic ASP and ASP.NET pages, and is running .NET 4.0 (version 4.0.30319.235; the latest, I believe) and the entire site is HTTPS (SSL). It uses ASP.NET Forms authentication with an LDAP provider (the corporation's LDAP in the same domain). It's a very straightforward authentication, with an LDAP connection string and provider configuration in the root web.config, and an "asp:login" control, using the defined LDAP provider, on the login page. The web site is configured with wildcard mapping in IIS to allow the classic ASP pages to be authenticated with the same ASP.NET login process. Sessions are the default "Inproc", not using SQLServer or a state service.
Intermittently, starting about 3 weeks ago, it has been taking 2-3 minutes for users to log in to the web site. There are some pages in the site that don't require authentication and those still perform fine, and after loggin in, authenticated pages also work fine without any delays. It's only the login process itself that's slow.
The exact same website configuration and code running on the development server and workstations never encounters the same delays in authentication.
The login code has not changed in well over a year, and the site has been running .NET 4.0 for probably a year; the servers were updated to the latest .NET version in October-2010. The wildcard mapping was also set up well over a year ago. The login slowness only started about 3 weeks ago. The web server department is not aware of any changes that were made around that time to the web servers and/or the network.
While the long delay occurs on the login page, I don't think the delay is actually in the authentication process; it seems to be in some sort of setup before that. I have added the setting of a Session variable with the current date/time to the beginning (in the LogginIn event) and end of the login code, and there is usually less than a second between these times; however, the clock time between clicking the "Login" button on the login page and the setting of the first of these Session variables is a couple of minutes (consistently around 2 minutes and 14 seconds). I have tried this with page buffering enabled and disabled with no difference in the times.
The same configuration and code is set up in these various environments:
(OK) Development server: Windows Server 2003 SP2 64-bit (32-bit IIS) in SSL mode
(OK) Development server: Windows Server 2008 R2 64-bit (32-bit IIS) in SSL mode
(OK) dev. workstations: Windows 7 64-bit (32-bit IIS), NOT running SSL
(Sometimes slow) Staging web server: Windows Server 2003 SP2 32-bit in SSL mode
(Sometimes slow) Production web cluster: Windows Server 2003 SP2 32-bit in SSL mode
That is, in the development servers and workstaions, I cannot seem to cause the same slowness no matter what I try - resetting IIS, recycling the app pool, updating web.config, etc.
The development servers are using self-signed certificates for SSL; the staging and production servers are using "official" (Verisign) certificates. The production web servers are also used for other web sites (and the other web sites are all still at .NET 2.0), but none of those other sites are using LDAP authentication. All machines (production and development) are up-to-date with Windows Updates.
I can reproduce the problem on the staging or production servers by forcing an application restart (such as by updating web.config) or asking for an IIS Reset, or (on the staging server) waiting for more than 20 minutes with no activity (I think, for the application pool default lifetime to end).
We have checked the following:
The "machineKey" section in every web.config in the entire site is identical
The application pool for the site is set to .NET 4.0, and no other sites are using the same application pool
The application pool identity is "NETWORK SERVICE"
We have tried the following in production with no change in the occasional login delay:
Adding connectionProtection="None" to the LPAP provider configuration
Adding an "applicationName" to the LDAP provider configuration
Adding a port number (the SSL/secure port number) to the LDAP connection string
We have looked through Windows event logs and the IIS logs on the staging and production servers, without finding an obvious connection to the issue. The only possibly-related error that does sometimes occur is the following (that's been logged sometimes about a second before the login succeeds, not at the time that the "Login" button was clicked), however, this may also be because a previously-logged in session has timed out:
Event code: 4006
Event message: Membership credential verification failed.
Application information:
Application domain: /LM/W3SVC/ [...]
Trust level: Full
Application Virtual Path: /
Process information:
Process name: w3wp.exe
Account name: NT AUTHORITY\NETWORK SERVICE
Can anyone suggest any other troubleshooting ideas or potential configuration issues that should be checked or changed?
You can take a memory dump when the problem is happening, and then you use windbg do the analysis.
How to take memory dump:
http://support.microsoft.com/kb/286350
This blog has lots information about how to analysis memory dump
http://blogs.msdn.com/b/tess/
I developed a e-commerce project. My project copies running on Server 2003 / IIS 6 with .Net Framework 4.0 .
Today, i have Server 2008 and IIS 7.5. Project is running normally but when i redirected https page, session is broken.
How do i fix it?
IIS creates different application pools for each http and https bindings. so session state will be different in each binding (protocol) so you can not access session from one protocol in other one, unless you set cookie in client machine or set cookie name for your session.
the simple solution is to set domain wide cookie in http page and retrieve it in https page!