Share via

Optimization Techniques for Solution Sites

  • Article

After measuring your site for bottlenecks and other performance issues, and setting performance goals, you can start tuning your site. This topic discusses some of the most common optimization techniques and their solutions.

Creating a static homepage

Profiling anonymous users

Limiting the number of constants

Tuning the size of existing caches

Caching custom content

Removing unused code

Porting code to Visual Basic

Creating a static homepage

Because static pages do not require database lookups or other Active Server Pages (ASP) processing, you can reduce latency by creating a static home page. Any reduction in dynamic content improves the capacity of your servers. However, creating a static home page may create difficulties if you have users whose browsers do not support cookies.

Profiling anonymous users

Implicit profiling of anonymous users can be a great way to collect information about how users interact with your site. However, the cost of the storing this information may not be beneficial if the information is not analyzed on a regular basis to improve your Web site. To stop profiling anonymous users, change the Site privacy options App Default Config property to two (2). For more information about changing App Default Config settings, see Configuring the App Default Config Resource.

Limiting the number of constants

Measurements indicate that having more than thirty-three constants in an ASP page causes Web site performance to degrade. One solution to this problem is to put all the constants into a type library.

Tuning the size of existing caches

When determining the size of a cache, consider the following: memory requirements of each fragment, the memory on your computer, the hit rate of a particular cache entry, and latency costs to compute each cache entry. In general, expensive calls should be stored in a larger cache than cheaper calls. For example, you may want to set the product cache size to 100,000 and the category cache size to 1,000 if product calls are more expensive than category calls, and the performance measurements indicate that although the product cache size is large, it performs faster than the respective property calls.

Caching custom content

Typically caching content is a much more efficient way to store content than calling object properties each time information is needed. Thus, if you add custom content to your Web site, you should look into caching that content.

When adding a new type of fragment cache, you must first initialize it in the file global_cache_lib.asp, which is similar to the initialization for the ProductList Fragment Cache. If the cache is catalog related, and you determine that it should be refreshed when the catalog changes, you must also add an oCacheManager.RefreshCache entry in the file BDRefresh.asp, so that when changes are made to the cache it will write to a table that will force the page to refresh with the newly updated information.

To determine which fragments are cached and which are not, uncomment the following three lines of debug code in the LookupCachedFragment function in the file include\std_cache_lib.asp:

If Not IsNull(LookupCachedFragment) Then
   LookupCachedFragment = "<TABLE BORDER=1><TR><TD>Cached: " _
   & sCacheName & BR & sCacheItemName& sLanguage & "</TD></TR><TR><TD>"_
   & LookupCachedFragment & "</TD></TR></TABLE>"
End If

This function puts a table cell around all the cached content, so that you visualize which content is cached.

For more information about creating a custom cache, see Code to Implement Custom Cache Components.

Removing Unused Code

If you do not implement all of the features available in the Solution Sites there is no reason to keep unnecessary code. For example, the user authentication code can be simplified if you do not need to support all of the login permutations.

Porting code to Visual Basic

Porting your ASP code to compiled Visual Basic is a fairly easy way to achieve additional performance in your site. However, there are many arguments to consider before porting your ASP code to Visual Basic. Deployment, versioning and debugging will be more difficult.

Copyright © 2005 Microsoft Corporation.
All rights reserved.