We currently have an ASP.NET Web Application running on a single server. That server is about to hit the danger zone regarding CPU usage, and we want to deploy a second server.
What would be the best way to handle Session State?
We currently run InProc. But that's not an option with 2+ servers, as we want to exclude a single server from the WLB rotation sometimes to do maintenance work. Even though we use sticky load balancing, we would have to wait for all users to exit before we can exclude the server from the WLB rotation.
So I was looking at this MSDN page: http://msdn.microsoft.com/en-us/library/ms178586(VS.80).aspx
I guess my main question is: If we use the State Server mode. Can we ensure rendudancy by deploying the state server across two servers? To avoid having a single point of failure.
If you want one of the standard options I'd use SQL Server in a failover cluster. BTW have you consider memcacheddb?
Sql State server would be a better option: This link might help Sql State Server
. I don't believe you can run state server across multiple machines.
Use either Scale Out State server (faster better) or SQL State (slower simpler). But beware if you store any none serializable objects into Session state, because you'll get exceptions after migration.
you might want to look into project velocity (http://msdn.microsoft.com/en-us/data/cc655792.aspx) . It has limited support now because it is on CTP3 but later this year it would be RTM. I highly suggest you watch the MIX09 session about it here
I would suggest looking into p2p Session State Server - link is here: http://www.codeproject.com/KB/aspnet/p2pstateserver.aspx
Worked for me. The only drawback is that if you have a large data set it was taking forever to replicate between peers.
Related
i have an application that runs normally in my first website.
If i move this applicatio to another server, but i don't move db (that remains to server 1), it runs very slowly to retrive data from sql.
The problem is only network or is there any issue in my code?
I use ADO.NET with LINQ...
Thank
If they were residing on the same server before and now their not, then yeah it's almost certainly a network issue. Are the servers housed in the same location? I'm taking a guess here since I don't have adequate information, but there's a chance that your intranet isn't configured correctly or you're using an external IP's. In that case one or both of the request and response are being sent out over the internet when they could be using your or your company's internal network to communicate.
Profile your queries. See how much time it takes to execute each. If your queries return fast, the problem might be your front-end code or the network.
You can log your Linq queries to console (or a Textwriter, for example). Something like:
dataContext.Log = Console.Out;
Then run the queries in SQL Server and see how efficient they are. Do they use indexes? Do they perform table scans? etc.
I am working on asp.net (newbie) and I am trying to understand what it means to do "load balancing" for the web site. The website will be used by multiple users and resources (database, web service,..).
If anyone could help me understanding the concept of the load balance for asp.net web site, I would really appreciate it.
Thanks.
One load-balancing-related issue you may want to be aware of at development time: where you store your session state. This MSDN article gives a good overview of your options.
If you implement your asp.net system using "out-of-process" or "sql-server-mode" session state management, that will give you some additional flexibliity later, if you decide to introduce a load-balancer to your deployed system:
Your load balancer needn't handle session affinity. As one poster mentioned above, all modern load-balancers handle it anyway, so this is a minor consideration in any case.
Web-gardens (a sort of IIS/server-implemented load-balancer) REQUIRES use of "out-of-process" or "sql-server-mode" session state management. So if your system is already configured that way, you'll be one step closer to being able to use web-gardens.
What is it?
Load balancing simply refers to distributing a workload between two or more computers. As a concept, it's not unique to asp.net. Although having separate machines for your database and web server could be called "load balancing" it more commonly refers to using multiple machines to serve a single role, such as having multiple web servers.
Should you worry about it? Probably not. Do you already have a performance problem? Are your database and web server on their own machines? If you do find that your server resources are strained, it would probably be easier to scale up (a more powerful single machine) than out (load balancing). These days, a dedicated box can handle a LOT of traffic if your code is decent.
Load Balancing, in the programming sense, does not apply to ASP.NET; it applies to a technique to try to distribute server load across two or more machines, rather than it all being used on one machine. Unless you will have many thousands (millions?) of users, you probably do not need to worry about it.
Check the Wikipedia article for more information.
Load balancing is not specific for any on technology stack be it asp.net, jsp etc. To load balance is to spread the incoming requests to a web site over more than one server. This is typically done with a software or hardware load balancer. The load balancer sits in front of two or more web servers and delegates the incoming traffic. Although this technique is not limited to web servers. Load Balancing
Enjoy!
I've never used it, but an option is IIS Application Request Routing.
IIS Application Request Routing (ARR)
2.0 enables Web server administrators, hosting providers, and Content
Delivery Networks (CDNs) to increase
Web application scalability and
reliability through rule-based
routing, client and host name
affinity, load balancing of HTTP
server requests, and distributed disk
caching
In a typical web server/database scenario, the db is almost always guaranteed to load up the machine first. This is because dealing with storing data requires more resources. Before you even start looking at load balancing your web server, you need to think about how to load balance the database.
Spreading one database across multiple servers is a lot harder than load balancing a web server. One of the techniques that can be used is sharding (or horizontal partitioning). This is where some records are stored on one server, and other records - on another server. For example records with ID 1-900000 are on server 1 and records 900001- are on server 2.
In comparison to DB load balancing, spreading the load across multiple ASP.NET servers is not overly complicated. Most of the session issues can be easily mitigated by using out of process session and/or never talking to Application.Cache directly. Data load balancing on the other hand is hard and requires a lot of planning and trial and error. In most cases, talking to a load balanced DB requires using an ORM which supports it (e.g. NHibernate) or your own Data Access Layer. The reason being is that you need to take out establishing a connection from the code that uses the database, so that the decision which DB to talk to is handled in one place.
the exact solution is to save session into the SQL Server with Stored Procedure. To read session call 'SessionCheck' stored Procedure.
I'd add that it really isn't something to worry about. By the time you need a load balancer, you can probably afford one of the neato newfangled ones with sticky sessions so you don't even have to deal with the session boogeyman.
I'm building a client-server application and I am looking at adding failover to the client so that when a server is down it will try to connect to another available server. Are there any standards or specifications covering server failover? I'd rather adopt an existing standard than implement my own mechanism.
I don't there is, or needs to be any. It's pretty straight forward and all depends on how you can connect to your sever, but basically you need to keep sending pings/keepalives/heartbeats whatever you want to call em, and when a fail occurs (or n fails in a row, if you want) change a switch in your config.
Typically, the above would be running as a separate service on the client machine. Altenativly, you could create a method execution handler which handles thr execution of all server calls you make, and on Communication failure, in your 'catch' block, flick your switch in config
You're question is very general. here are some general answers:
Google for Fault Tolerant Computing
Google for High Availability Solutions
This is usually handled at either the load balancer or the server level. This isn't something you normally do in code at the client.
Typically, you multihome the servers each having their own IP + one that is shared between all of them. Further, they communicate with each other over tcp for the heartbeat to know which is the Active node in an Active / Passive cluster.
I can't tell what type of servers you have, but most of the windows servers can do this natively.
You might consider asking the question at serverfault to see how to properly configure your servers to support this.
I have an ASP.Net website on IIS7 and I am planing to increase the MaxProcesses to match the number of cores on the server (4 cores, 64bit Windows Server 2008).
From what I read, if I increase the MaxProcesses to create a web garden I have to set an out-of-process state server, so I am planing to use the ASPState service to share sessions between worker processes.
But there is something that is not clear to me, is Caching also shared? Or do I have to set a new custom provider for the cache?
In-process cache is never shared in a web garden.
But here's the REAL thing... I question the motivations behind what you're doing. If the object is to use your cores more efficiently, then you can just increase the number of request and/or worker threads you have running your ASP.NET application. Running multiple w3wp processes isn't necessarily the option you want. If you have some constrained resource, like an old in-process COM object that scales poorly with threads, then I can see how you might scale better with multiple processes. But unless you really know what you're doing and why, gently step back from that setting and leave it at 1. ;-)
Caching is not shared. The web garden creates multiple "w3wp" processes. Each process will have its own cache.
If you want to share cache then use something like MemCached Win32 (with the Enyim cache client) or use the new MS product Velocity. This way once you move beyond one server you will already be set up architecturally to handle it.
StateServer or SQLServer?
What is the best solution for storing ASP.NET session variables?
What are the pros and cons of each?
Are one better then other in any particular situation?
Here's some thoughts about pro's/con's.
I've also added Microsoft Velocity Distributed Caching solution.
Pros for InProc
Fastest optional available (it's all in memory/ram)
Easy to setup (nothing new required in the .config file .. i think this is the default behavior).
Most people I believe use this.
Cons for InProc
If the web site (application pool) dies, then all session info is lost.
Doesn't work in a WebFarm scenario -> session information is per app pool only.
Cannot contain non-session information.
Pro's for a StateServer
In memory/ram, so it's fast (but has some net latency .. read below), so it might not be as fast as Inproc.
Default configuration for a web farm scenario. Multiple iis sites use a stateserver to control the state session info.
Con's for StateServer
Requires the ASP.NET StateServer service to be set to run.
StateServer requires some config tweaking to accept 'remote iis machine' requests.
There's some tiny tiny net latency if the iis request needs to grab/set the session info on another networked machine.
Cannot contain non-session information.
Pro's for SqlServer (as a state server)
State is always retained, even after the iis site restarts.
Con's for SqlServer (as a state server)
Slowest solution -> net latency AND hard-drive latency (as the sql server stores the state on the harddisk / reads from the harddisk).
Hardest to setup/configure.
Cannot contain non-session information
Pro's for Velocity (or other distributed caching systems)
Can handle more than just session information -> objects, application settings, cache, etc. (This is a very GOOD thing IMO!!)
Can be memory only or persist to a database.
If one 'node' fails, the system still works. (assuming there's 2+ caching nodes)
Con's for Velocity (or other distributed caching systems)
Generally cost $$$
Hardest to setup (have to install stuff, tweak configs, add extra specal code).
Has network latency (which is generally nothing) but could have hard disk latency IF the service is persisting the data (eg. to a Sql Server).
I think the assumption would be that you are using a web farm of some sort.
One use of state service is in a Web Garden (multiple worker-processes on the same machine). In this case, you can use load-balancing to keep a user's connection going to a particular server, and have the n worker processes all sharing the same state service.
EDIT: In the web garden + state service or sql server scenario, you also have the benefit of being able to recycle the worker processes on that machine w/o the connected clients losing their session.
I'm not as familiar with using SQL Server as a session state store, but I would think you would gain robustness by using an SQL Server in a cluster. In this case, you could still have multiple worker processes and multiple servers, but you would not have to use a sticky session (server affinity).
And one more note, you can use state service on a second machine, and have all server in the farm hit that machine, but you would then have a single point of failure.
And finally, there are 3rd party (and some home-grown) distributed state-service-like applications. Some of these have performance benefits over the other options, plus Session_End event will actually fire. (In both State Service and SQL Server session backing, there the Session_End in Global.asax will not fire (there may be a way of hooking into SQL Server)).
In an n-tier environment, with SQL Server hosting session state you'll create additional network traffic to your back-end, as well as losing some SQL Server resources that will need to now take care of that additional traffic (session-related requests). SQL Server state management is also slower than state server.
However, if your servers go down in some unforeseen incident, SQL Server will most likely maintain the session information, as opposed to a state server.
In my personal experience I had a few problems storing in session variables. I kept loosing the session and I believe it was the anti virus, which, as it was scanning every file in the server, IIS would recompile the site killing the sessions. (I must say I had no power over that server, I was told to host the app there)
So I decided to store the session in the SQL Server and everybody is happy now... it is incredibly fast
Take a look at this article for a quick start up
Using a single machine to store state in a web garden means a single point of failure. We use SQL state, but it does add a bit of overhead.
In Proc is very Fast.
But having limitation. we can use single system only.
When the time of reboot the System, information will be lost.
worker processes in same machine
StateServer stored the session information in other machine.
Web Farm can use the session. for ex: multiple worker-processes can access the session information from server.
When the time of rebooting server, information will be lost.
SQLServer is used to store the info in Table. Default it will store in TempDB.
This tempdb will dynamically call after sqlservice is called.
So this also not persist the data. In this Scenario we can store in our own DB using Script, that is called Custom Option.