Common Web Tier Bottlenecks

Common Web Tier Bottlenecks

Web tier bottlenecks can occur due to many reasons such as configuration problems, lack of hardware resources, inefficient design, or use of code. It is always useful to eliminate configuration issues by keeping your build documentation and build scripts up-to-date and verifying your configuration, especially when major code changes occur.

Effective stress testing can assist you in determining if your Web application will scale up or out by adding additional hardware. Assuming your Web application can scale, one method is to throw more hardware at your application. The downside to this is that it often requires more support hours, because there is more hardware to manage. There is a more detailed discussion on scalability at the end of this chapter. The best method of meeting or exceeding your performance goals is to identify the bottlenecks and fix or tune the code. This method is a cyclical process and requires performance testing and tuning throughout the software development life cycle. In this section we discuss some general best practices and also share our experiences with some of the newer, more effective coding techniques currently available.

Real World Configuration Problem

To illustrate a possible configuration problem, let s say you recently deployed a Web application from your development environment to your production environment. Of course you completed performance testing of your Web application in the development environment and have benchmark results or numbers that you can compare against a test in your production environment. In analyzing the performance data (counters and IIS logs), you notice much more data being passed from the test conducted in your production environment. Also, the throughput numbers for the test in your development environment are much higher. You expected much more throughput in your production environment because the hardware is more powerful and you used the same test scripts and the same amount of stress clients for both tests. You then log on to your production Web server to troubleshoot configuration differences between each environment. Finally you discover that Trace and Debug were both enabled in the Web.config file on your development environment just before it was copied up to the production servers.

Limiting Page Size

One of the most common bottlenecks we often encounter from the Web tier is a result of the dreadful never-ending page. Passing too much data per page can cause performance issues on both the IIS server and network tier. This may seem very obvious, but many Web applications we analyze suffer from slow response times as a result of having pages that are simply too large. Do not be afraid to divide up the content when necessary. This may cost your users an additional click to get to the data they are looking for but your content will load much quicker. Here are some other tips which can help to provide your end users with a better experience and quicker response times:

  • If your Web application returns huge record sets, look into paging the results.

  • Remove white space and comments from your code or HTML. This sends less data over the wire.

  • Remove unused styles from your stylesheets.

Limiting Images

Optimize all images and use them sparingly or when they provide some kind of value to your Web application. Reusing the same image causes less network round trips because most browsers can cache the image on the client, and not have to go to the Web server to get the image each time. It is more efficient to use one larger image than multiple smaller images. Quite often images are used for advertisements and are loaded from another site outside of your control. You should be aware that this creates a dependency on another site that you cannot control and in extreme cases can cause your page to timeout if the resource becomes unavailable or becomes extremely slow when loading. If your site is very dynamic and graphically intensive, consider splitting your dynamic content and your images to separate Web servers and tune each accordingly.

Using Naming Conventions

Come up with a naming convention that makes sense and is readable but keep the directory structure as flat as possible. Keep file, directory, and variable names short and sweet, and abbreviate whenever possible. By doing this you will pass less data in each request, which can really make a difference because it is common to reference many file types (like images, StyleSheets, client side scripts, and so on) within HTML. You should avoid a directory structure like the following URL, which contains 68 characters:

http://yoursite/goodoldunitedstatesofamerica/northcarolina/pictures/

Just by abbreviating the directory structure you can eliminate 41 characters for just one request.

http://yoursite/us/nc/pics/

Disabling SSL

Use SSL only when necessary or required within your Web application. Test your pages with and without SSL enabled to determine the impact of encrypting your data. Generally speaking we notice a 20 to 30 percent decrease in performance by using SSL. If you organize your content effectively you can create distinct folders which house content so you can enable or disable SSL per directory. In most cases there is no need to enable SSL for images, stylesheets or other file types such as client-side scripts.

Trying New Features

As new programming methods and features become available, do not be afraid to test them out. Many new coding features are designed not only to provide additional functionality but to gain performance over previous methods used to solve various problems. For example, Response.Execute has been available for some time now, but we still frequently see people using Response.Redirect within their ASP/ASPX code. When you use Response.Redirect your users will incur an additional network round trip for the same operation. We have also seen many .NET Web applications which suffer major performance problems stemming from inefficient string manipulation or concatenation within loops. Using the new .NET StringBuilder class often resolves this problem and can add huge performance gains when concatenating many strings together in a loop.



Performance Testing Microsoft  .NET Web Applications
Performance Testing Microsoft .NET Web Applications
ISBN: 596157134
EAN: N/A
Year: 2002
Pages: 67

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net