Chapter 10 Achieving Optimum Performance with PowerDynamo

Converting an inefficient Web site to an efficient Web site

Let's say that the high-volume Web site "Hockey" has an average of one request every two seconds, 24 hours a day. Half the data being accessed changes at most once a day (statistics, player info etc.) while the other half is constantly changing (game scores, penalties etc.).

For a Web site such as this, each area of the site must be looked at and inefficient or unnecessary processing eliminated.

We'll look at four key areas to ensure that the Web site is operating as efficiently as possible.

The Web documents
The document cache
The use of scheduling
The connections

If you use Windows NT, you can use the Performance Monitor to monitor your Web site's performance. For more information see "Using the Performance Monitor".

Working with documents

Any document that takes longer than two seconds to execute can slow down the system. Wherever possible, documents must be as specific as possible so queries can execute as quickly and take no longer than the time between requests to complete. Ideally, each request should receive 100% CPU time. If this goal is attained, requests are processed at maximum efficiency.

Another practice that leads to performance degradation is putting multiple queries in one script. Again, each document should be as specific as possible. It is far more efficient to have many specific documents than to have fewer general documents. More specific documents allow you to take advantage of output caching.

Categorize your documents

By categorizing your documents and setting them up accordingly, much processing time can be eliminated. Categorizing automatically uses caching and scheduling to enhance performance. You can categorize each document into one of the following three categories:

Data that changes less than once an hour or documents that take a long time to execute - Schedule these documents to run on a regular basis. This makes the output readily available for subsequent requests.
Data that changes once an hour or more often - Assign appropriate cachedOutputTimeOut values to these documents.
Refer to "Setting a cachedOutputTimeOut value" for more information.
Data that is constantly changing and must be accurate to the minute and documents that take parameters - do not set cachedOutputTimeOut values for these documents or schedule them with the scheduling wizard. Ensure that the cache size is set high enough to hold their source so those requests can be processed as quickly as possible.
A cache size should be set that is appropriate for the Web site that will be utilizing it. It is important that the size of the cache is large enough to hold all the active documents for at least a brief duration of time. If a cache size is too small, the stored document output and source may be flushed to make room for more recent documents before they have a chance to be re-used before being unloaded.

Working with connections

There are several ways for a Web author to control the way connections work within a Web site:

Setting a connection timeout
Setting maximum and minimum number of connections
Creating permanent or temporary connections.

Connection timeout value

The first value you should set to increase performance is the connection timeout value. The default connection timeout value of 0 indicates that all connections remain in the connection pool. Because of the fluctuating traffic that our Web site receives, this is not what we are looking for. For the best performance for this Web site, we will set the connection timeout value to 15, which holds a connection in the pool for 15 minutes after the last time it was active . The number of connections stored in the connection pool fluctuates with the Web site volume. This produces better performance than constantly creating new connections or keeping enough connections in the pool to always cover the peak times of volume.

Next, we will look at the maximum and minimum number of User connections for our Hockey Web site.

User connections

At peak times our Web site uses a maximum of 20 User connections. Since this is manageable without slowing down the overall performance of the Web site, we can set the maximum number of User connections to 20.

Number of User connections
Caching document output and scheduling documents may greatly reduce the required number of User connections for your Web site.

During the slow times, there is a minimum of four User connections per definition being used at any one time. By setting the minimum number of User connections to four, we ensure that four connections will always remain in each connection pool ready for use.

Dynamo connections

The minimum and maximum connections for User connections applies per definition . The minimum and maximum number of connections for Dynamo connections is a total since each Web site has only one Dynamo connection. For example, suppose there are two User connections defined in the connections folder of Sybase Central; "sales_db" and "marketing_db", setting a minimum number of user connections to four would mean that eight connections would be held in the connection pool, once created.

Our Hockey Web site requires a slightly smaller number of Dynamo connections than User connections. The maximum number of Dynamo connections will be set to fifteen and the minimum number of Dynamo connections will be set to five.

Use of permanent and temporary connections

Finally, let's look at whether our Web site is using temporary or permanent connections within its scripts. We need to ensure that temporary User connections are used only in the appropriate instances. Scripts that use temporary User connections that are reused in day to day Web use should be changed to permanent User connections to minimize the processing required to create a new connection each time.

For more information on connections see "Working with connections".