Scalability depends on many factors, including the
hardware used, the types of content and applications deployed, and the
amount of available RAM. This section discusses ways Windows Server 2008
and IIS 7.0 greatly improve your applications.
IIS 7.0 offers many
features to help with scalability. Kernel-level caching, Dynamic
Compression, and Integrated Pipeline are some of the features that can
help you out.
During Design
Probably nothing has
more impact on scalability than the design phase of an application. You
can deploy a sample and test it under load in a controlled environment
during the design phase.
Understanding the Application’s Nature
Understanding your
application well can help with scalability. Is most of the data dynamic
or static? If the application has portions that are static, you can look
at caching portions of it. Are the higher volume pages static or
semi-static information? Determining this can allow you to take
advantage of IIS 7.0 caching features.
Other factors that can
help with scalability are such things as whether your application stores
information in text or XML files, and whether or not most of the
information is database-driven.
User Base
Another critical
requirement you should take into account is your user base. Sometimes we
overlook who will be accessing our applications. Are most or all of
your users local to your company, or are most of your users
Internet-based?
Knowing your user base
during all phases of application development, testing, and rollout
provides a more realistic set of expectations concerning the time when
real users will start using your application. When you’re testing your
application with your expected user base in mind, do try different
scenarios under different loads.
Understanding how your
user base will use your application and how the application acts under
different situations is key to a more predictable, scalable application.
Scale Up or Out
The age-old IT question: Should you scale up or out? The answer is: it depends.
Web Farms
A
Web farm is a group of two or more servers used to host a Web site. Web
farms help increase the capacity of a Web site and improve availability
by having redundant servers. Web farms are commonly used for
high-traffic and mission critical Web sites. Here are factors to
consider when attempting to run a single Web site on several servers:
Content placement
Session management
Network Load Balancing
Content placement can be a
key architecture and scalability question. You can either keep the files
locally on the Web servers or place them on a remote file server. For
single server deployments, keeping the content local to the server will
have performance benefits and will be simpler to support. For Web farms,
you can keep the content local on the server. However, you’ll need to
implement some type of file replication to keep files in sync across all
machines. If your Web site has several changes or thousands of files,
keeping them in sync can be challenging.
The other
option regarding content placement is to store content on a remote file
server. Your IIS servers would be the front end to the remote content.
Keeping the content on a remote file server has many benefits, including
a single source of content; greater efficiency when making updates;
easier rollback changes than if your content was stored on each web farm
node; and a remote file server that could be a SAN (storage area
network), which has faster disks than local server disks.
You’ll need to
consider a few registry tweaks when you implement Universal Naming
Convention (UNC)–based content. The Web server has one registry added,
and two registry entries are added to the remote file server. See the
following procedures for instructions to implement the changes.
To configure the registry key on the file server, follow these steps:
1. | From the command prompt, type regedt32 to open the registry.
|
2. | Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters.
|
3. | If
it doesn’t exist, create a DWORD “MaxMpxCt” registry entry and set the
value to 800 hexidecimal. This will specify a value of 2048 decimal.
|
4. | If
it doesn’t exist, create a DWORD “MaxWorkItems” registry entry and set
the value to 2000 hexidecimal. This will specify a value of 8192
decimal, or four times the “MaxMptCt” value.
|
To configure the registry key on the Web server, follow these steps:
1. | From the command prompt, type regedt32 to open the registry.
|
2. | Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters.
|
3. | If
it doesn’t exist, create a DWORD “MaxCmds” registry entry and set the
value to 800 hexidecimal. This will specify a value of 2048 decimal.
|
Session management can be
tricky in a Web farm. Depending on the application, you can support
session state in a Web farm scenario in a variety of ways. For Classic
ASP–based applications, you normally have some type of sticky state
implemented on your load-balancer, which redirects the client to the
original server that handled the initial session. All requests are
redirected to that particular server for the entire session. That type
of behavior can impact load on other servers, depending on traffic.
If you are using the
built-in NLB feature in Windows Server 2008, the term for redirecting
the session to the same server is called affinity.
ASP.NET applications support various modes of session state. In a Web
farm deployment, you need to either use a remote ASP.NET session state
server or use a SQL Server session state server. The SQL Server solution
could be a clustered set of machines that provides failover. The
ASP.NET state server and SQL Server session options are the two
available options provided by Microsoft. They scale well for
applications requiring state management functionality. Third-party
solutions are available to support InProc and replication of session and
cache objects to other machines. The best option is to architect your
applications to be stateless and not require session management. A
stateless application provides for a more flexible application that
should scale better in a Web farm deployment.
Web farms can be
important when scaling your application. Before you proceed with scaling
up or out, consider that a Web farm is probably the most cost-effective
choice and is a great return on investment.
Web Gardens
We discussed Web gardens and how to help with scalability.
Using Web gardens can help scale up and scale out on the same hardware.
Systems that are multiple processor cores will automatically support Web
gardens. In your efforts to increase scalability, Web gardens can be an
option when your systems have multiple CPU cores.
Hardware Upgrade
Upgrading
your existing hardware is sometimes overlooked when an application
issue occurs. Usually, an administrator will consider bigger and faster
hardware versus looking at the existing machines. Before you go to the
expense of and asking for approval to purchase new hardware, first
understand what is happening. If you determine the machine is
CPU-constrained, consider adding more processors. A typical CPU costs
less than a new machine. If you find that RAM is the bottleneck,
consider adding more to the existing machine. RAM can greatly help with
server performance. If disks are your bottleneck, consider looking at
moving the content to a SAN, if you have one deployed in your
environment. This will extend the life of the server and help with
application performance.
Consider the following
example. You could have a Web farm that has two nodes. The server’s CPU
usage averages 30 percent to 40 percent, with spikes to 60 percent and
higher. Traffic has increased to a point at which performance has become
an issue. After using the Reliability and Performance Monitor, you
determine there are spikes due to CPU usage. The servers have single
processor (two processors with hyperthreading) installed. Adding
processors to the server, which is dual processor–capable, lowers the
average CPU usage from 30–40 percent down to 10–15 percent. The
processor costs $300 per machine. The total cost is $600 ($300 per
machine times two machines in the Web farm) versus adding another
machine, which could cost several thousand dollars. This is one example
of extending the life of your current hardware instead of adding more to
a Web farm or replacing servers that meet your needs.
NLB
NLB, or Network Load
Balancing, directs requests to multiple servers to support your Web
site. There are a few options when directing traffic to your Web farm.
Round-robin is an option that enables you to direct requests evenly
across all machines. Least-active supports sending requests to Web
servers that are using the least amount of resources. Sticky-state, or
affinity-based requests, sends the request back to the original server
that started the session. Fastest reply sends requests to the server
that’s responding the quickest. Windows Server 2008 offers a built-in
NLB option that supports multiple dedicated IP addresses. Many major
vendors provide multilayer load-balancers. For higher traffic sites,
evaluating Microsoft NLB and third-partyload-balancers is recommended
before deciding which solution to choose. Using load-balancer technology
can help provide high availability and redundancy and can help your
application scale.
