In this section: |
To develop a comprehensive set of benchmark test cases, consider the following sizing elements.
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.
Primary components for which we need to allocate resources are:
Database server usage is any activity that requires a connection and processing of a data request to and by the database server.
WebFOCUS Reporting Server usage is any activity that requires the use of the WebFOCUS Reporting Server. These include but are not limited to:
Presentation layer usage is any activity that requires the use of the WebFOCUS Client and ReportCaster front-end tools. These activities include, but are not limited to:
Response times and job throughput capacity will be impacted if there are not enough resources for components to service requests, which may violate SLAs.
System resources must be captured for each physical tier in the architecture. It is best to do the following:
System resources that should be monitored are:
The database server is also very CPU-intensive, and that is why most customers must separate the Data Layer from the Reporting and Metadata Layer. Having both layers on one machine will most likely result in resource contention.
Memory can be physical or virtual, but in this documentation, we will focus on physical memory. Virtual memory and swapping statistics can be captured and added as a resource that has to be sized. The ReportCaster Distribution Server uses more memory than CPU. The WebFOCUS Client, which is comprised of a number of web applications, runs within a JVM that is memory-intensive. The JVM must be configured to use appropriate memory, referred to as JVM heap size. There is a minimum and maximum heap size, which is how much memory the JVM should start with and the maximum it can use.
Depending on the design of the physical architecture, network bandwidth can impact performance. Application performance will reflect the performance of the available network bandwidth.
Monitoring disk activity with a tool like Microsoft® diskperf™, or the equivalent on other operating systems, is important for many reasons. It will allow you to track the number of requests that are queued and waiting for a disk, to see if it is a bottleneck. It will allow you to measure the size of input/output (I/O) operations.
We need to understand how much disk space to allocate for the current workload and future workload growth.
WebFOCUS 8 requires a database repository to store content created by the Presentation Layer. You need to understand how much data is expected to be stored.
The recommended size of your tables will vary from one implementation to another. For more information on recommended table sizes utilized by Resource Analyzer, see the Resource Analyzer Administrator’s and User’s Manual.
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.
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.
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.
The data and data sources are critical to sizing. We must have a thorough understanding of:
These can be Enterprise Data Warehouses (EDW), Data Marts, or Operational Data Stores (ODS). If it is an EDW, we need to know if and when ETL jobs are launched so we can address any type of resource contention if reporting and ETL jobs overlap.
It is also critical to know the database architecture, tables, and table relationships, and most importantly, the size of the tables. Is the data in the tables static or dynamic? What is the frequency of data growth? Naturally, performance will be impacted if there is a lot more data to scan.
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
Available network bandwidth may have a significant impact on performance and the ability to meet SLAs.
Information Builders |