Web Dev: Optimizing Web Servers

Configure your Web application servers for high performance

Developing Web sites involves far more than creating an application and posting it to a server. A Web application interacts with many components such as Microsoft Internet Information Server (IIS), Active Server Pages (ASP), Microsoft Transaction Server (MTS), servers, and load-balancing hardware. On a large scale, a Web application is a client/server application. Because of its complexity, Web development requires careful planning and testing to build and maintain high-performance applications.

An often overlooked aspect of building Web applications is the Web server's hardware and software configuration. The most complex part of the application is usually the server the application will run on. Because the server hosts the application, it's imperative to optimally design and maintain the server and understand the application's impact on it.

Access the Servers

The first step is to determine the Web application's function, then plan the type of server you'll need. If the application will host 10 to 100 users at a time, you don't need much planning to make the servers work acceptably. You can simply install IIS and SQL Server on the same physical hardware, add a fair amount of memory (a minimum of 256MB), and add a fast processor (300MHz or better). If the server has enough memory and CPU horsepower for the database and the tasks the application performs, you won't have problems. If you need to query a large thousand- or million-row database or you have more queries than usual to process, the processor demand will go up, the server's performance will suffer, and you'll need to upgrade to a larger server.

You need to prepare for anticipated increases in the number of simultaneous users. I've seen sites that run fine with 200 to 300 simultaneous users and then blow up when the company runs an advertising promotion and 2000 visitors hit the site in the same day. So start with server architecture that will handle many users, and the application will scale effectively.

You need to put SQL Server on its own server when you plan to use a large Web application that hosts a thousand or more simultaneous users. However, large is relative. Some applications with only a few hundred users will require their own servers while other applications won't require dedicated servers until the application has more than a thousand users. Ideally, the server should run only the SQL Server application. Put as much memory into this system as you can afford because SQL Server probably will need it. You can start with one processor, but a good multiprocessor system will provide a way to easily upgrade the number of processors as demand increases.

The disk subsystem for the SQL Server system needs to provide high-performance features such as fast disk access and RAID support hardware. The disk should also include fault tolerance capability such as RAID 5. RAID implementations (except for striping only, which is RAID 0) require overhead to support fault-tolerance features. So to avoid extra overhead, if you don't need fault tolerance in the drive system, don't use it. For example, you can use RAID 0 or a fast drive with no RAID support. For more information, such as the number of drives to use and what to put on each drive for performance and recoverability, see Morris Lewis, "9 Ways to Optimize SQL Server 6.5 Queries" (January 2000).

You need to isolate application servers that run IIS and MTS and host ASP and components for the application. Typically, each of these application servers will be part of a Microsoft Windows NT Load Balancing Service (WLBS) cluster. Any COM component that ASP accesses should also run on each of the application servers.

Use Memory Effectively

As with SQL Server, IIS and MTS need sufficient memory to work effectively. I recently encountered an ASP application that ran erratically on a client. When users first accessed certain pages, the pages took a long time to load. But during successive access attempts, the pages loaded quickly. The first time a user accessed the page, ASP compiled it and loaded it into the cache, which took significant time. When users subsequently accessed the file, the process was much faster because the file was already in the cache (for a while). Eventually, the first file dropped out of the cache because users accessed other ASP files, which replaced the first file.

One way to solve a slow access problem caused by no available memory is to add more memory to the Web server, which makes the IIS cache larger. Then, when you run SQL Server and other applications on the application servers, the applications run more efficiently because they don't compete for memory with IIS's applications.

Another way to decrease file-access time is to tweak Windows NT to use memory in the server more effectively. To do so, go to the Control Panel Network applet. Click the Services tab, and open the properties for Server service. Set the Server properties to Maximize Throughput for Network Applications, as Screen 1 shows. These server configuration parameters control how NT handles IIS and other applications. When you select Maximize Throughput for Network Applications, NT will tune its memory management for applications instead of files and printers. When you select another option, NT will page to the disk part of the IIS working set (part of the InetInfo process) when it needs memory. This process will drastically slow your application's performance whether you're using ASP or only HTML code.

Also, you need to make sure the Web server is set to the default, cache all ASP requests. If not, you can change this setting on the server's Application Configuration Properties, Process Options. Then, you can open the Internet Service Manager (ISM) and right-click the server name to access the Web page. Select WWW Service in the list, click Edit, then click the Home Directory tab. Next, click the Configuration button, then click the Process Options tab. For more information about these settings, see my Windows 2000 Magazine article "Tweaking NT and IIS for ASP Applications" (March 2000).

Consider Load Balancing

Another piece of hardware you might think about using is WLBS to balance the incoming user load on each Web server. Many public sites that serve tens of thousands of users use WLBS. You can configure WLBS to manage your server's user load and easily add new systems later to scale your Web site as necessary. For example, let's suppose your site managers anticipate increased site use because of upcoming online holiday shopping. After you add a new server, WLBS takes part of the load from IIS and MTS and lets these applications handle their usual number of users, then scales to a larger number of users for a short period.

A Few Final Tips for Your Plan

You need to optimally configure the servers for the task they're performing. You can configure the application servers with WLBS and configure the other servers with SQL Server to run as one system with only SQL Server databases. The databases need to use indexes, stored procedures, and other techniques to optimize performance. You can also cluster the SQL Server machines, so each application server can run on a dedicated server in the WLBS cluster.

The larger your ASP file is, the more time it will take to load and compile. I've seen several cases of ASP pages that are only a few hundred lines long but include files that add thousands of lines to each page. IIS can't keep all the pages of a file this size in the cache. You can shrink the amount of code in your ASP pages by moving many of the support functions from the include file to COM objects. The code in a set of COM objects can compile to machine code and usually will execute faster than ASP code. In fact, with minimal effort, you can move much of the ASP code you already have into COM objects; I'll discuss this process in a future column.

You'll want to take advantage of the various technologies your servers offer, one of which is using stored procedures and views in SQL Server for most or all data access instead of inserting dynamic SQL code in the ASP or Visual Basic (VB) code. Using dynamic SQL will make SQL Server execute much slower than using views or stored procedures for the same task. Other technologies such as MTS and Microsoft Message Queue Server (MSMQ) can also provide application performance benefits. MTS provides scalability for components by managing the instantiation of objects and providing other runtime support. MSMQ can enhance scalability by providing an easy way to separate an end-user application from a database. MSMQ works best in applications that don't require realtime database access, queuing of transactions, and data movement that can offload processing and eliminate application bottlenecks.

Take advantage of the available technology when you develop Web-based applications. If you apply an optimal hardware configuration and understand how different application components interrelate, you'll build a scalable, fault-tolerant, high-performing Web application.