MSDN Magazine - April 2008 - (Page 66)

the compute time on the client doesn’t change as the number of clients increases. The other elements of the performance equation also remain consistent as you scale. But compute time on the server will need to be tuned as the number of users increases. The trick to optimizing server code is to use testing to be sure you’re actually making a difference. You should use profiling tools to analyze your application and find out where the application is spending the most time. The entire process should be empirical: use tools to find the code to improve, improve the Getting rid of affinity is a code, test to see that you key goal of distribution. This have actually improved requires moving session performance, rinse, lather, repeat. In really largescale state data out of process, sites, you’ll often hear per which means taking a formance tuning like this performance hit. compared to the job of painting the Golden Gate Bridge: once you finish painting the entire thing, it’s time to go back to the beginning and start again. I’m always amazed at the number of people who believe that the starting point of scaling is distribution. “Throw more hardware at it,” they yell. Don’t get me wrong; without a doubt, adding hardware can help. But without specialization and optimization, the return can be small indeed. Specialization lets you distribute smaller parts of your applica tion as needed. If you’ve separated out your image servers, for ex ample, it’s easy to scale your image services independently of the rest of the application. Optimization also provides dividends for distribution by re ducing the amount of work needed for a given operation. This translates directly into fewer servers needed to scale to the same number of users. Affinity Optimizing the Code Load Balancing To implement distribution you need to add servers, duplicate the application across them, and implement load balancing. For load balancing, you can use Network Load Balancing (NLB), a service included with all editions of Windows Server® 2003. With NLB, every server is an equal partner in the loadbalancing rela tionship. They all use the same algorithm for balancing, and they all listen on a shared virtual IP address for all traffic. Based on the loadbalancing algorithm, each server knows which server should be working on a given request. Each server in the cluster sends out a heartbeat to let the other servers know it is alive. When a server fails, the heartbeat for that server stops and the other servers com pensate automatically. NLB works well when you have a large number of users making fairly similar requests. However, the compensation mechanism does not work as well in a scenario when some requests create a much greater load than others. Fortunately, for that type of situation there are hardware loadbalancing solutions available. 66 msdnmagazine ASP.NET Performance Ultimately, the challenge of effective distribution lies in elimi nating affinity. For example, when you have only one Web server, storing session data there makes perfect sense. But if you have more than one Web server, where do you keep session information? One approach is to keep it on the Web server and use affinity. Essentially, this means the first request from a given user is load balanced, and after that, all subsequent requests from that user/ses sion are sent to the same server as the first request. This is a simple approach, every load balancing solution supports it, and in some cases it even makes sense. In the long run, however, affinity creates grief. Keeping session data inprocess may be fast, but if the ASP.NET worker process re cycles, all those sessions are dead. And worker processes recycle for a lot of reasons. Under high load, IIS might recycle the worker process of ASP.NET because it thinks it’s stuck. In fact, by default in IIS 6.0 a worker process is recycled every 23 hours. You can adjust it, but either way, your users are vulnerable to losing their session data while it is inprocess. When you’re small, this isn’t that big a deal, but as your site gets bigger and busier it becomes a more sig nificant issue. And there’s more. If you’re load balancing by IP address, one server is going to get hit by a megaproxy (like AOL) and be unable to service that entire load on its own. Plus, updating your servers with a new version of your application becomes more difficult; you must either wait for hours to let users to finish up on your site or annoy those users by knocking them out of their sessions. And your reliability becomes an issue: lose a server and you lose a lot of sessions. Getting rid of affinity is a key goal of distribution. This requires moving session state data out of process, which means taking a per formance decrease to provide a scalability increase. When you move session out of process, session data is recorded in a place where all the Web servers can access it—located either on SQL Server® or the ASP.NET State Server. This is configured in web.config. There’s also a coding effort needed to support outofprocess ses sion. Any classes that will be stored in the Session object need to be marked with the Serializable attribute. That means that all data in the class needs to either be serializable or be marked as Non Serialized so it will be ignored. If you don’t mark up your classes, when the serializer runs to store your session data out of process, you’ll get errors. Finally, moving session out of process is a great way to find out you have too much data in your session object, because you’re now paying a price for shipping that great big blob of data back and forth across the network twice (once to retrieve it at the be ginning of the page, once to return it at the end of the page) for every page request. Once you nail down the Session object, go after other affinity issues like Membership and Role Manager. Each one has its own challenges for eliminating affinity. But for your ASP.NET applica tion to really scale up, you’ll need to hunt down every form of af finity you can find and eliminate it. All of the strategies we’ve discussed thus far are applicable to practically every Web application that needs to scale. In fact, those

Table of Contents Feed for the Digital Edition of MSDN Magazine - April 2008

MSDN Magazine - April 2008 Contents Toolbox CLR Inside Out Basic Instincts Cutting Edge Foundations Test Run Service Station Windows with C++ Going Places { End Bracket }

MSDN Magazine - April 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.