Planning for capacity means determining the hardware needed for your system to perform well under its anticipated workload.
Capacity planning is a challenge, because it involves many variables, some of which are difficult or impossible to measure. It is the science of measuring known variables and developing an educated estimate of resource requirements on the basis of those measurements. It is also the art of allowing for unknown variables and assessing their impact on the estimates derived from the known variables.
To determine your IBM Cognos 8 capacity requirements, gather information about the following:
IBM Cognos 8 users
Estimate the number of IBM Cognos 8 users you expect to have, and when you expect them to use IBM Cognos 8.
application complexity
Assess the complexity of the processing that your users will demand of IBM Cognos 8.
your infrastructure
The characteristics of your environment and infrastructure.
Capacity planning is an ongoing process. After implementing IBM Cognos 8, monitor and modify your capacity as necessary to meet your performance expectations.
In general, the greater the number of users, and the more concentrated their requests over time, the more hardware you need for a system to perform effectively. As a result, when planning adequate capacity for IBM Cognos 8, you should estimate the number of people who will use IBM Cognos 8 and determine when they will use IBM Cognos 8. This can help you decide not only how much hardware you need, but also how to make the best use of the hardware you have.
The only users placing load on IBM Cognos 8 are those who are actually performing processing. These are concurrent users. You can estimate the number of concurrent users, based on your total user population, by distinguishing between named, active, and concurrent users:
named users
Named users are all of the users authorized to use IBM Cognos 8; that is, your total user population.
active users
A subset of named users, active users are logged on to IBM Cognos 8 and can demand system resources.
concurrent users
A subset of active users, concurrent users are simultaneously demanding system resources. This includes users submitting requests and users waiting for a response to a request.
As a general rule, the ratio of named to active to concurrent users for business intelligence applications is about 100:10:1. In other words, for every 1000 named users there are 100 active users and 10 concurrent users.
The concurrency ratio can vary over time, and is affected by many factors. For example, the number of concurrent users relative to active and named users tends to be higher when the user population is small. However, the most important determinant of the concurrency ratio is how processing demand is distributed over time.
In IBM Cognos 8, load is generated by
user navigation and processing requests, such as requests to run or view reports
requests made through automated or event-driven processes, including scheduled and burst reports
By determining when users are most likely to be using IBM Cognos 8 and submitting processing requests, you can decide when to schedule automated processes. This allows you to distribute the processing load evenly over time, so that you make the best use of your system resources to maintain optimal performance. The key to doing this is estimating the number of concurrent users that will be applying load to your IBM Cognos 8 system at any time.
Factors such as business hours, business practices, and the geographic distribution of users can determine how the concurrency rate changes over time, and how you choose to ensure adequate capacity.
A business intelligence application in which requests are spread evenly throughout the day has a lower peak concurrency ratio than an application in which the majority of requests are limited to a specific time of day. For example, if users are concentrated in one time zone, there will likely be heavy demand during business hours, followed by a period of low demand after hours. In this situation, you may be able to manage peak and non-peak time periods by sharing hardware resources between interactive and noninteractive processes. You would schedule automated activity to run in non-peak times to produce content for retrieval by interactive users in peak times.
On the other hand, if your user population is distributed across several time zones, user load on the system tends to be spread out over more hours, and there are fewer available non-peak hours for scheduled activities. In this situation, you may choose to dedicate separate hardware resources for interactive and noninteractive use.
Knowing how user load is distributed helps you decide when to schedule automated processes. Scheduling can be applied to two types of reports:
scheduled reports
These reports often depend on updated, event-driven information, such as sales data for the previous day.
burst reports
These are reports for which multiple users require filtered data based on a predetermined schedule. Burst reports are used when a common report format is applicable to more than one recipient, but each recipient requires customized information.
Scheduling is most useful for reports based on data that is updated on a predictable and cyclical basis. For example, an organization may need to produce sales reports based on information from the previous day, and make them available to users at the start of each business day. If users generate these reports at the beginning of each day, it creates considerable load on the system. By scheduling the reports to be triggered by data refresh, and run during non-peak times, the capacity required at peak times is reduced.
For information about tuning report scheduling and bursting after IBM Cognos 8 is implemented, see IBM Cognos 8 Tuning. For information about how to schedule reports, see the Administration and Security Guide.
Load is not only determined by the number of concurrent users, but by the complexity of their processing requests. The greater the complexity of a request, the more time is needed to process the request. In general, hardware resources can process more requests in a given time period when the requests are simple rather than complex. As a result, application complexity is an important determinant of the number of concurrent users that can be supported on a given hardware infrastructure.
The complexity of an IBM Cognos 8 application depends on such things as the amount of work required to process the result set returned from the database query, and the size and layout of the report output. Size is determined by the number of pages in a report and the presence of elements, such as charts.
By identifying reports run at peak times, and improving their efficiency while meeting user requirements, you can improve performance during peak times. Because reporting patterns change over time, assessing application complexity, and improving reporting efficiency, should be ongoing activities. For more information, see Performance Monitoring and Tuning.
IBM Cognos 8 performance also depends on the characteristics of your infrastructure.
Ideally, IBM Cognos 8 server components should be connected by a network with 100 Mb of available capacity. Network bandwidth between a Web browser and a Web server does not affect system scalability, but does affect user performance.
Use true server computers, rather than fast workstations. True server computers run business applications faster and provide systems that are less likely to fail.
Will Web and application servers be dedicated solely for use by IBM Cognos 8, or shared by other software products? If other applications are sharing the resources, these applications must be taken into account when determining capacity requirements.
Install only gateway components on server computers that are dedicated to Web server processing. Web servers are designed to handle many small requests. Application servers often handle larger requests.
Use the gateway type most appropriate for your environment. For example, for some environments, ISAPI or Apache may provide better performance than CGI.
The complexity of your security infrastructure can increase response time. As your security infrastructure becomes more complex, a user request must be validated more frequently. For example, if you implement multiple network firewalls, each firewall must validate every request that passes through it. This can increase the time taken to complete the request. In addition, if you use SSL, the overhead of SSL encryption adds both processing overhead and size to the response.
Because notification service generates additional email traffic, ensure that your mail server can scale to support the increased load.
The content store is used by Content Manager to store all IBM Cognos 8 information that is visible in, or managed through, IBM Cognos Connection or your third-party portal. The content store is at the heart of IBM Cognos 8, and must have sufficient resources to operate effectively. To maximize IBM Cognos 8 performance and scalability, ensure that your content store has the resources required to ensure that it does not become a bottleneck.
The size of the IBM Cognos 8 content store you need depends on the number and size of the IBM Cognos 8 items, such as reports, packages, and schedules, that you will create and store. Over time, as users create more items, the amount of space needed for the content store typically increases.
When determining the amount of space to allocate for your content store, consider the following:
number of users
The greater the number of users, the greater the number of reports typically run and stored, and the larger the content store needed.
number of saved reports
The greater the number of reports saved, the larger the content store needed. Reports designed for use throughout an organization, and stored in public folders, are often duplicated by users in private folders. This increases the number of reports stored and the space required for them.
number of saved views
The greater the number of report views saved, the greater the space required.
number of folders
IBM Cognos 8 typically uses public folders as well as one or more private folders for each user. The number of characters in the name and description of each folder can increase the folder size.
number of schedules
Schedules can exist for daily, weekly, and monthly print runs. The greater the number of schedules, the greater the content store space required.
number of Framework Manager packages
The greater the number of packages, and the number of tables and query subjects in those packages, the greater the space required.
additional storage items
Additional storage items, such as transaction logs and temporary space requirements, increase the size of the content store required.
The size of an empty content store hosted in a MS SQL Server database is approximately 2 to 3 Mb. Depending on your size allocation strategy, this may vary for other supported databases.
The number of concurrent users affects the size of the content store because temporary disk space is allocated to serve report run requests, even if the requests are not saved.
Out of 50 concurrent users, approximately 25% will be executing reports and 75% will be viewing saved outputs. As a result, approximately 12.5 of the 50 users will be running reports (50 concurrent users * 0.25 executing reports = 12.5 concurrent users).
The following table provides an example of how to estimate the size of the content store you need.
Factor | Number | Estimate of content store requirements (Kb) |
Named users | 1000* | not applicable |
Active users | 250* | not applicable |
Concurrent users (temp space requirements) | 50* | 5,000,000 |
Saved reports: 1-10 pages (2 per user for Public and Myfolder copies at 340 Kb per report) | 1001 | 340,340 |
Saved reports: 10-100 pages (9 per user for 4 Public and 5 Myfolder copies at 440 Kb per report) | 5,004 | 2,201,760 |
Saved custom views: 1-100 rows (3 per user, all Myfolders at 250 Kb per view) | 3,000 | 750,000 |
Saved custom views: 100-1000 rows (8 per user, all Myfolders at 350 Kb per view) | 8,000 | 2,800,000 |
Folders (Public and Myfolders) | 1,025 | 500 |
Framework Manager models | 15 | 100,000 |
Framework Manager models (tables) | 25 | -- |
Framework Manager models (query subjects) | 50 | -- |
Schedules (day and week) | 175 | 5,000 |
Empty content store | -- | 3,000 |
Database transaction logs | -- | 3,000,000 |
Total | -- | 14,200,600 |
*As a rule of thumb, the ratio of named to active to concurrent users is 100:10:1. However, the ratio varies with the environment. For more information, see Estimating Concurrent Users. | ||
For more information about capacity planning, visit the IBM Cognos Customer Service Center (http://www.ibm.com/software/data/support/cognos_crc.html).