Specifying Default Prompting

Models can include reports that prompt the user with a descriptive name while filtering on a code or key value for improved query performance.

You can modify a model to ensure that queries sent to the data source are efficient, well formed, and secure. To ensure optimal performance, the Framework Manager modeler can

• specify the rules governing query generation

• restrict user access to specific rows or columns of data

• model data relationships to hide the complexity of data from report authors

For more information, see the Framework Manager User Guide.

Setting Query Processing Type

For relational metadata, you can improve performance by selecting the right type of query processing.

There are two types of query processing:

• limited local

  The database server does as much of the SQL processing and execution as possible. However, some reports or report sections use local SQL processing.

• database only

  The database server does all the SQL processing and execution. An error appears if any reports or report sections require local SQL processing.

Although the database server can usually run the SQL and run reports much faster, local processing is sometimes necessary. For example, choose limited local processing if you want to create cross database joins or if you want report authors to use unsupported SQL99 functions.

Some complex queries, such as a query that must generate an At clause to avoid double-counting, require limited local processing. In this case, the query automatically uses limited local processing even if the package was published with database only processing.

For more information, see the Framework Manager User Guide.

Setting the Process Capacity

Each Cognos 8 dispatcher is assigned a process capacity. It dictates the number of requests that will be handled by a server. By default, request distribution uses a weighted round-robin algorithm that distributes requests equally among all configured dispatchers. In this case, the process capacity for each dispatcher is assigned a weight of 1.0.

The process capacity should be configured according to the relative performance of each server. For example, consider a two-server topology. If all other variables are constant, a quad-processor server should be configured with a processor capacity of 2.0, and a dual-processor server given a processing capacity of 1.0. This means that in the two-server topology, one server receives twice the number of requests as the other.

For more information, see the Administration and Security Guide.

Specifying Advanced Dispatcher Routing

Depending on how your system is set up, you may want to control how reports are distributed among servers. For example, you have different departments that maintain their own servers, or you have specific servers set up for specific data access, such as Windows server for Microsoft SQL Server databases and Linux servers set up for DB2 access. You can set up Cognos 8 so that report requests are processed by specific servers by applying routing rules to specific packages, groups, and roles.

For more information, see the Administration and Security Guide.

High Affinity Connections

High affinity requests apply to the report service only, and not to the batch report service. A high affinity connection is used to handle a high affinity request, and each connection handles one request at a time. A high affinity request is a transaction that can benefit from a previously processed request. It can be processed on any of a number of servers, but resource consumption is minimized if the request is routed back to the report service process that was used to execute the original process.

Each report process has a configurable number of high affinity connections. The number of high affinity connections to set should be based on the number of low affinity connections set for each report process, as well as the capacity required for other services on the same server.

The distribution decision between high and low affinity connections per batch report process should be a function of the anticipated distribution of request types. For example, an HTML reporting application may have a greater likelihood of high affinity requests than a PDF reporting application. The page down request for an HTML report uses a high affinity connection whenever possible.

In general, we recommend that the number of batch report service and report service processes should be the primary parameter to be optimized when deploying a Cognos 8 application. After system resource use is configured to operate efficiently, the number of affinity connections can be tuned for further optimization.

Note: If the number of affinity connections per process is set too high, the process may be overburdened with managing connections. This will result in competition for system resources, and requests will take longer to complete due to inefficient use of server resources.

Low Affinity Connections

A low affinity connection is used to handle a low affinity request. Each connection handles one request at a time. A low affinity request will operate just as efficiently on any server.

Both the report service and batch report service are capable of handling low affinity requests. Low affinity requests that have been initiated by scheduled activity will make use of the low affinity connections configured for a batch report service. Low affinity requests that have been initiated by user-driven activity will make use of the low affinity connections configured for a report service.

Each report and batch report process has a configurable number of low affinity connections. The number of low affinity connections per report service process should be set in coordination with the settings specified for the batch report service.

The distribution decision between high and low affinity connections per process should be a function of the anticipated distribution of request types. For example, an HTML reporting application may have a greater likelihood of high affinity requests than a mainly PDF reporting application. The page down request for an HTML report uses a high affinity connection whenever possible.

In general, we recommend that the number of report service and batch report service processes should be the primary parameter to be optimized when initially deploying a Cognos 8 application. Once system resource use is configured to operate efficiently, the number of affinity connections can be tuned for further optimization.

Note: If the number of affinity connections per process is set too high, the process may be overburdened with managing connections. This will result in competition for system resources and requests will take longer to complete due to inefficient use of server resources.

Affinity Level of Cognos 8 Activities

Cognos 8 includes the following high affinity activities:

• Report Viewer links

  • Run again

  • Return

• HTML report navigation

  • Top page

  • Page up

  • Page down

  • Bottom page

• delivery options

  • Save

  • Save As

  • Print

  • Email

  • Viewing

Cognos 8 includes the following low affinity activities:

• report querying

  • reporting

  • report processing

• report authoring

  • metadata retrieval

  • query validation

• administrative

  • testing data source connections

  • adding objects (folders, jobs, schedules, etc.)

  • refreshing portal page

Using Jobs to Schedule Reports

Reports can be scheduled on an individual basis. However, if you have many reports to schedule, scheduling on a one-by-one basis can become burdensome. As an alternative, you can use jobs to execute scheduled activities.

A job is a container of scheduled processing activities that operates in a coordinated manner. Instead of scheduling individual reports, a job allows multiple reports to execute using the same schedule. Each activity within a job is given a sequence ordering, which is based on how the job was selected.

Jobs can be submitted to run as follows:

• all at once

  All activities in a job will execute simultaneously. This execution strategy is particularly useful when the number of activities within a job (or multiple jobs) is less than the total number of low affinity connections available during the execution period.

• in sequence

  The activities in a job will execute one at a time, based on their sequence ordering. This execution strategy is particularly useful when the number of activities within a job (or multiple jobs) is more than the total number of low affinity connections available during the execution period. In this case, batch report throughput can be maximized by setting an equal number of jobs as available for low affinity connections. The number of activities per job would be set up so that the total number of activities results in the completion of the batch reporting requirements.

Job and Scheduling Service Settings

All scheduled activity is managed by the job and scheduling service. The job and scheduling service is directly related to the batch report service, and should be considered in tandem with that service.

Settings for the job and scheduling service include the following:

• Maximum Jobs During Non-Peak Period

  The maximum number of jobs during non-peak periods identifies a configurable limit to the number of jobs that can simultaneously execute during the specified non-peak period range.

• Maximum Jobs During Peak Period

  The maximum number of jobs during peak periods identifies a configurable limit to the number of jobs that can simultaneously execute during the specified peak period range. If an application does not perform scheduled activity during the specified peak period range, this setting is inapplicable.

For information about these and other job and schedule service settings, see the Administration and Security Guide.