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
{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}
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.