Share via

Optimizing Application Design and Administration

  • Article

Applies To: Windows Server 2003, Windows Server 2003 with SP1

You can often improve the performance of your Web server by paying attention to the design and administration of your Web applications and by upgrading hardware components to support fast application response times.

Upgrading Hardware to Improve Application Performance

Several types of hardware upgrade can significantly improve application response times on your Web servers:

  • Upgrade or add processors. Web applications benefit from faster processors.

  • Add memory. Adding memory can improve application response times if applications are running within their own processes.

Optimizing Application Design

Check this list for general application design guidelines that can optimize performance.

  • Use static files wherever possible. Typically, static files require much less processor time than do files with dynamic content.

    If you are generating pages dynamically to satisfy user preferences, consider substituting as many as 10 or 20 static variations for a single dynamic page. If you are generating dynamic pages to provide frequently updated data, redesign your application so that it generates a single static page on a fixed schedule and stores that page for retrieval until the next update.

  • Use managed code (C# or Microsoft® Visual Basic®  .NET), Microsoft ASP.NET, or ISAPI applications. C# and Visual Basic .NET applications usually run faster than ASP applications because the run-time environment executes compiled code. All of these types of applications typically run faster than equivalent CGI applications.

  • Enable ISAPI and ASP.NET output caching where possible, which allows HTTP.sys to cache the response and serve requests for the applications from the kernel instead of transitioning to user mode. For more information about tuning ISAPI output caching, see Tuning ASP Metabase Settings.

  • Avoid transitions from managed code to unmanaged code in your applications, if possible.

  • Enhance database-driven performance by using Microsoft SQL Server. Create and maintain good indexes to minimize I/O during database queries. Also, use stored procedures, which take much less time to execute and are easier to write than ASP scripts designed to do the same task.

  • Design your site so that applications push the processing load onto the client.

    Client-side checks reduce roundtrips and help to avoid network latencies, conserve server-side resources, and allow changes to appear instantaneously to the user. For example, add client-side code to validate that forms are filled out with good data, such as checking that credit-card numbers have a correct checksum. However, the server must still validate the data, because malicious clients can send malformed data.

Optimizing the Design of ASP Applications

Check this list for ASP application design guidelines that can optimize performance.

  • Turn off ASP debugging, and verify that both the AppAllowDebugging and AppAllowClientDebug metabase properties are set to false.

  • Avoid storing apartment-threaded components in ASP application or session state. Remove Visual Basic objects from ASP Session state if they are apartment threaded.

  • Cache output from ASP if possible; if not, cache inputs to ASP if possible.

  • Convert scripts in ASP pages into COM objects. Scripts in ASP pages are interpreted; if a script involves one or more loops, converting it to a COM object can improve its performance considerably.

  • ASP is now able to run all of its threads in a multithreaded apartment (MTA). If your COM components are primarily free-threaded or both-threaded, running the ASP threads as MTA can improve performance significantly. To enable all ASP applications to run in an MTA, you can use the metabase property AspExecuteInMTA at the application level. For more information about designing ASP to run its threads in MTA, see Configuring Applications to Use COM+ Services.

  • If an ASP script is more than 100 lines (counting lines of code in included files), consider creating a COM+ component to provide the same function. If COM+ components are written efficiently and debugged properly, they can offer 20 to 30 times the processing speed of a script for the same dynamic page.

    Tip

    The easiest way to measure the size of an ASP script with #include directives is to change the file name extension of the page from .asp to .stm, and then open the .stm file by using your browser. Use your browser's View Source command to display the .asp file and lines of code from the included files.

Optimizing Network Administration and Design

Check this list for network administration and design guidelines that can optimize performance.

  • Set HTTP expire headers for all images and for HTML so that proxy servers and browsers make fewer calls to the Web server. For information about setting an expiration date for Web site content, see Using Content Expiration.

  • Use SSL certificates only when needed and only for content that requires security. Because SSL uses complex encryption that consumes considerable processor resources, it takes much longer to retrieve and send data from SSL-enabled directories. Therefore, only secure the files that contain or receive sensitive information, such as credit-card numbers or medical information. Also, keep these pages free of other elements that consume resources, such as images. For more information about implementing an acceptable level of security while preserving performance, see Balancing Performance and Security.

  • Minimize initialization processing wherever possible. For example, enable caching, when appropriate; on multiprocessor computers, assign processor affinity to better use CPU caching; and use HTTP compression for faster downloads. For information about caching, see Monitoring Overall Server Memory. For information about using compression on different file types, see Using HTTP Compression for Faster Downloads.

  • Run IIS in worker process isolation mode, which allows you to periodically restart worker processes assigned to an application pool (either manually or automatically by using preconfigured settings). Recycling worker processes can help minimize problems attributed to faulty Web applications.

  • Establish Web gardens, which are application pools that can run multiple worker processes.

  • Stress-test applications in your lab before you place them on a production server.

  • If you have a large installation with many FTP sites, each attached to a different IP port, your server might create too many backlog monitor threads (the system creates a thread for every 64 sites). The workaround for this is to disable the backlog monitor. To disable the backlog monitor, set the value of the DisableBacklogMonitor registry entry to 1 and then restart the FTP services. The DisableBacklogMonitor entry is located in the following registry subkey:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Inetinfo\Parameters

    Warning

    The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference.

  • If you expect a large spike in traffic on a particular page or set of pages, you can change that page or set it to static HTML for a few days. Switching from a dynamic page to static HTML can involve some redesign, but the effort is often worthwhile. For example, when many thousands of people, during a short period, traverse three or four scripted pages to get to a particular download page, your server uses a lot more resources than it needs to. To save time for your users, you can instead provide a temporary static front page that has simple navigation.

For information about editing the registry, see the Registry Reference.