Elements of Resource Sizing and Capacity Planning

In this section:

To develop a comprehensive set of benchmark test cases, consider the following sizing elements.


Top of page

x
Application Information

Having a thorough understanding of WebFOCUS application usage is critical to sizing in many ways. If the WebFOCUS systems are shared between different business applications, you must account for that usage when sizing.


Top of page

x
Sizing Components

Primary components for which we need to allocate resources are:


Top of page

x
System Resources

Response times and job throughput capacity will be impacted if there are not enough resources for components to service requests, which may violate SLAs.


Top of page

x
Query Workloads

WebFOCUS queries can be the following workload types:

Guided Ad Hoc Query Workload. These are queries submitted from a browser and returned to the browser. Sample queries include:

Ad Hoc Query Workload. These are queries and visualizations that are built by production users using ad hoc tools, such as InfoAssist and InfoDiscovery.

Batch Query Workload. These are ReportCaster scheduled jobs.

Integrated Query Workload. This is a mix of guided ad hoc, ad hoc, data discovery workload, and batch queries that simulate mixed usage patterns.


Top of page

x
Peak Processing Time

It is important to identify the critical processing times for each query workload in order to do the proper sizing. If during the hours of 7AM to 9AM most users sign in and run reports, then resources will have to be adjusted and prioritized accordingly.


Top of page

x
Service Level Agreement (SLA)

A Service Level Agreement is an agreement between a service provider and its users. For example, there may be an established SLA within an organization that requires a WebFOCUS report to run and return the report output within five seconds. SLAs are typically user-driven, but can also exist in other areas, like administration. For instance, a systems administrator has to create a database for a business unit within three business days after the request has been submitted. Most companies have established Service Level Agreements (SLA). Some are measured in response times and resource utilization, others in job throughput.

Response Times and Resource Utilization

The response times and resource utilization captured from submitting a request and receiving a report can be broken down into different levels and can be built around peak or off-peak times. Typically, it is built around peak times.

Some customers want the total elapsed time and resource utilization percentages.

Some customers want a breakdown of the elapsed time at multiple levels, as in the following, where an SLA is comprised of two parts:

Throughput Capacity

Throughput is typically measured as a Unit of Work (UOW). For instance, in an SLA that is based on job throughput, the UOW can be the number of reports per minute or per hour. The SLA may be ten UOWs per hour or one UOW per minute.


Top of page

x
Enterprise Data

The data and data sources are critical to sizing. We must have a thorough understanding of:


Top of page

x
User Population

For existing workloads, we can determine the user population and usage patterns from captured statistics. With new applications not yet in production, we do not have statistics for establishing usage patterns, so we have to use a rule of thumb (ROT) or some other means.

Sample for Usage Patterns

Total Named Users

= 100%

Signed-on Users (accessing the Presentation Layer simultaneously)

=35% of total named users

Concurrent Users (hitting the WebFOCUS Reporting Server or ReportCaster Distribution Server and Database Server simultaneously)

=5% of Signed-on Users


Top of page

x
Network Bandwidth

Available network bandwidth may have a significant impact on performance and the ability to meet SLAs.


Information Builders