Running a Windows Web server is becoming expensive and will soon cost even more. The next version of Windows .NET Server will be more expensive than Windows 2000. Factoring in the additional costs of ongoing maintenance for endless security patches and service packs, and the expense of rapidly depreciating hardware has left me thinking about how to handle my Web-server load on the fewest number of servers.
I believe that two properly tuned Web servers can handle all the traffic of any major Web site if they use caching. I am calling this the "Just Two" theory and will try to explain how to make just two Web servers handle all your traffic.
I know for some this will be hard to swallow, since there are companies running five, twenty, forty, and a hundred server farms for a single Web site. How can it be done with just two Web servers?
Let's step back and take a look at what the Web server is doing and does best, what Web server software vendors would like us to do, and what kinds of things we can expect from our Web server.
What the Web Server Does Best
Windows 2000 Server is a very complex operating system that was designed to handle a multitude of tasks, such as being an Exchange server, Web server, file system, or SQL server. As a Web server it is very good at handling authentication. It is also good at executing dynamic pages like ASP and Allaire's ColdFusion, and making sure those pages can connect easily to databases.
Serving static files and images is the simplest of all Web server tasks, and Internet Information Server (IIS) is good at serving them. However, it is not cost efficient to use a sophisticated and expensive IIS server to handle these types of files when there are cheaper and faster ways to serve static content.
Consider that graphics, static files, and streaming media comprise the bulk of Web content. Why should anyone continue to update, maintain, and pay for a farm of Windows 2000 servers to handle what can be served by something no more complex than a hub or a switch?
Recommendation #1
Use a simple reverse proxy server to handle simple requests like static files, graphics, and streaming media. Use a complex Web server to handle complex requests like dynamic page execution.
A reverse-proxy caching appliance runs a simple Web server. Reverse proxies can be deployed in front of your IIS Web servers to reduce load on them and improve their capacity to handle dynamic page requests. Furthermore, caching appliances are low maintenance, don't have the security problems that IIS Web servers have, and they can be reused in front of any Web server type, should you change your preference.
Try purchasing two inexpensive and low-maintenance caching appliances like F5 Networks, Inc.'s EDGE-FX server to handle static Web pages, graphics, and binary files, and downloads.
To be fair, reducing the number of Web servers that you run by purchasing additional hardware isn't really making all your traffic run on two Web servers, however, the overall goal is the same -- reduce your total IT costs by running cheaper equipment in place of more expensive equipment. Secondly, I understand it's very hard to justify purchasing additional hardware to replace hardware already on hand. Just think of it as an expansion option.
What the Vendor Wants
Realize it's not in Microsoft's best interest to reduce the number of Web servers you need to handle all your traffic. Nor is it in the best interest of the hardware vendors. However, in fairness I believe that Microsoft tries to make the best possible products with all the necessary features and performance levels. Typically though, companies use Microsoft products because of the features, like Active Server Pages, and not the functionality, like speed. The point is that it is in your best interest to reduce the number of IIS Web servers you run and don't look for relief from Microsoft anytime soon. Secondly, all the features that Microsoft allows you to use on your IIS Web server adds to the overall functionality, but can seriously degrade performance.
Here is an example: N-Tier architectures are easy to design and hard to design correctly. Most companies that use a COM object layer between their Web pages and database are dealing with threading issues incorrectly. Because of this, their really big Web servers are only able to process a small number of pages. If you have a two-processor Web server with 512 MB of RAM, your Active Server Pages use COM objects, and the processor is pegged at 100 percent at 10 Get Request/sec, you are doing something wrong (more below). Getting your threading right is in your best interest, and it can be the difference between deploying twenty Web servers or two Web servers.
Recommendation #2
Create the simplest Web sites that use the least amount of Active Server Page features. Choose Web site features according to their demand on the Web server and keep the overall expense minimal. Don't expect the next version of Active Server Pages or IIS to be faster.
What to Expect from Your Web Server
Information about what to expect from your Web server and your Active Server pages is really lacking in the Active Server Page and Internet Information Server community. There are a few case studies floating around, but they are specific and hard to compare to your Web server. One of the problems with setting expectations is that people are running a wide variety of Web sites with a wide range of traffic patterns. However, I've worked with a large number of Web sites over the years and after taking a look at some of our client Web sites, I am willing to go out on a limb and tell you what I think the Web server should be able to do.
To understand how the Web server is operating you need to look at counters available in the performance monitor. Keep in mind, not all counters are meaningful. For example, the number of "Web Service\Current Connections" your Web server is handling at any one time doesn't matter. This number varies based on your load balancer, the connection timeout on your Web server, and whether you have instructed the Web server to "Keep-Alive". If you are concerned about this counter, try turning "Keep-Alive" off. The counter will go down, however, your server will work harder.
One counter that you should be watching is Web Service/Get Requests/sec. This is the number of requests coming into the server and is a gauge of how much traffic is being handled. If you are running a two-processor machine with 512 MB of RAM and requesting a variety of page types, you should be able to handle 50 Get Requests/sec at 20 - 40 percent CPU load. During peak load (100 percent CPU utilization) you should be able to handle 200 Get Requests/sec.
If you are getting less than 20 Request/sec and are running at 100 percent, you probably have a context-switching problem. Check the Threads/context switches/sec performance counter. If it averages above 10,000, then you are running too many threads, or have a threading issue with your COM objects.
If you are getting less than 20 Request/sec and are running at 10 percent CPU utilization, you have a problem with overly complex database calls (the page is waiting on the database), or you have COM objects using the wrong threading model, or you are using Microsoft Transaction Server incorrectly.
One way to dramatically increase the number of Get Requests/sec your IIS Web server can handle is to reduce the number of times an Active Server Page is called. The easy way to do this is to use a caching product like XCache Technologies' XCache that will turn your Active Server Pages into static pages temporarily. With XCache you should be able to handle 300-400 Get Requests/sec at 100 percent CPU utilization. Notice that XCache changes the makeup of the request, allowing the server to serve more static requests -- which are faster and simpler than dynamic requests. (Note: In order to test over 200 Requests/sec you are going to need special stress tools, an extra switch, and a least two testing machines.)
Another option is to use XCache to move your cached dynamic pages to the caching appliance that you purchase after reading Recommendation #1 (see above). Because XCache changes your pages to static pages, they can now be served from the caching application. Typically these appliances can do 100 - 400 Get Requests/sec.
Another way to get more Get Requests/sec out of your machine is to tune it. Either read the IIS 5.0 tuning white paper by George Reilly (see http://www.microsoft.com/windows2000/techinfo/administration/web/tuning.asp) and modify the registry and metabase yourself, or use a product like XCache's XTune to set the modifications automatically. Tuning your Web server can improve performance and scalability by a factor of two or three.
Recommendation #3
Use tuning, caching, and reprogramming to make your Web server perform at 50 Get Requests/sec or more.
Now the Numbers
A well-tuned and properly configured IIS Web server should handle at least 50 requests per second. Doing a little math, that translates to 4,320,000 requests per day.
50 requests per second * 60 seconds per minute * 60 minutes per hour * 24 hours per day = 4,320,000 requests per day
Every enterprise Web site should deploy at least two servers in a load-balanced or fail- over configuration. Better safe than sorry. Doing a little more math, a two Web server farm should be able to handle about 8,640,000 requests per day.
If half of the requests are for static files that are handled by the caching appliance, the total requests per day should be at least 17,280,000. Compare this against your Web logs, typically recorded as hits, and see if this meets the demands of your Web server.
Since the two Web servers will peak to 100 requests per second. The Web server can handle uneven amounts of peak traffic.
If you are in the top tier of Web sites that have more than 17 million requests per day, then you are going to need two more IIS Web servers in another co-location facility for redundancy.
By the way, I recommend two Web servers because you need the redundancy of those servers to do maintenance and to compensate for hardware failures. This is the same reason I recommend two caching appliances.
Disclaimer
Notice that multiple Web sites on a single box, complete Secure Sockets Layer (SSL) Web sites, and Web sites that require authentication on their static files were not discussed. If you fall into this group, there are options -- like an SSL hardware application to remove SSL load from your Web server. These can be integrated into your load balancer.
Summary
I challenge you to reduce your Web servers to "just two," and if you want, I am up to the challenge of helping you.
Wayne Berry is the architect of XCache Technologies' XCache and XTune. He is a former Microsoft design engineer, founder of 15 Seconds, and one of the top Active Server Page developers in the country. Berry's expertise includes software design, performance consulting, development, marketing, and online business. Berry served as a software development engineer at Microsoft and as editor of 15 Seconds prior to founding XCache Technologies.
A popular speaker, Berry has been invited to speak to international ASP developers' conferences, BackOffice Conference, and Internet World. He has authored several technical books, including ActiveX Programming Unleashed, Windows NT Registry Guide, and Special Edition Using Microsoft Internet Information Server 4.0, as well as many articles in print and online trade publications.
Berry holds a B.S. in computer science from Western Washington University.
Email him at wayne@xcache.com.
XCache combines dynamic content caching technology with content delivery network (CDN) support options, file compression and a whole lot of manageability features to help e-businesses deliver superior web site performance and reliability. You'll appreciate the administrative ease, your
visitors will appreciate increased page delivery speed.
XCompress works by compressing outgoing text between the Web server and the client. Page response times may improve by a factor of three or more while overall bandwidth use can drop by two thirds or more.
XCompress runs on Windows 2000 and Windows NT 4.0 and is tightly integrated with Microsoft Internet Information Server (IIS) with MMC and COM interfaces.
XTune 2.0 is the most powerful tuning application for IIS 4 or IIS 5 ever
conceived. Indispensable to the enterprise and straightforward, this web
tuning tool allows you to configure hidden operating system, network, Active
Server Pages and Internet Information Server settings for better
performance, without any additional hardware or software.
This version scans your system more deeply, offering more
performance-enhancing recommendations and greater insight into your web architecture. The Performance Wizard guides and teaches you throughout the complete tuning process, so you can learn while making your box run better than ever.
Performance monitoring helps organizations identify performance bottlenecks. The problem is that with so many performance numbers available, how do you know which ones to watch? This article helps you identify which are the critical performance counters in a SharePoint Portal Server environment and explains how to monitor them. By monitoring performance regularly, organizations can recognize performance trends as they develop and prevent problems before they get out of hand. [Read This Article][Top]
There is broad-reaching debate about remoting, Web services, Enterprise Services, and DCOM. In short, it is a debate about the best technology to use when implementing client/server communication in .NET. Rocky Lhotka shares his thoughts on the issue while offering clear explanations of basic application architecture terminology. [Read This Article][Top]
This article examines some of the new and exciting caching features in ASP.NET 2.0 and shows how to implement them in Web applications. [Read This Article][Top]
When it came time to find a technology for its massive upgrade, Match.com chose .NET. Has the online dating service's partnership with Microsoft been as successful as the relationships it has established for many of its millions of members? Read on ... [Read This Article][Top]
Longtime 15Seconds discussion list member Tore Bostrup offers valuable advice on designing databases and applications for efficient querying. [Read This Article][Top]
Narayan Veeramani shows how ASP.NET developers can improve application
performance by caching data stored in an Oracle database and keeping
the cached data in sync with the data in the Oracle database. [Read This Article][Top]
Ever developed a Web application that requires extensive processing? Ever had long running Web pages that often time out in the browser? Greg Huber reveals a simple technique that uses Microsoft Message Queuing (MSMQ) and the System.Messaging framework to handle long running Web processes. [Read This Article][Top]
As IT professionals try to reduce the cost of operating their Web sites, they should consider reducing the amount of bandwidth usage. Learn how to successfully compress your HTML output and save money on your monthly bandwidth. [Read This Article][Top]
Members of the 15 Seconds discussion list put together a couple of scripts to benchmark methods for removing duplicate items in a string list. [Read This Article][Top]
Mailing List Want to receive email when the next article is published? Just Click Here to sign up.
