IBM Cognos Real-Time Monitoring Sizing Guide

SIZING GUIDE

I OVERVIEW
This document will help sales/pre-sales as well as solution architects correctly recommend the
appropriate environment for the Real-time Monitoring capability within the Cognos 10 portfolio.
IBM Cognos® Real-time Monitoring is an actionable business intelligence solution which addresses an
enterprise’s real-time monitoring needs for the operational frontline. Designed for the Fortune 1000
enterprise, IBM Cognos Real-time Monitoring delivers self-service, interactive dashboards with easy to
develop operational KPIs and measures to support your organization’s operational KPI monitoring
agenda.
IBM Cognos Real-time Monitoring is a solution for consumers of actionable business intelligence that
provides an organization’s frontline with rich, visual operational KPIs and measures for supporting up-tothe-moment
decision making needs. Actionable BI provides the business with immediate contextual
intelligence giving workers insight into relevant operational drivers to make accelerated decisions. These
accelerated decisions drive actions that have optimal impact on business operations in real-time such as
call center agent utilization, marketing lead monitoring and SLA monitoring.
Customers can choose to deploy Real-time Monitoring standalone, or in conjunction with other Cognos
10 platform capabilities. This sizing guide focuses only on the Real-time Monitoring component, but
where relevant includes Cognos 10 platform requirements if leveraged.
Licensed Materials – Property of IBM 2
Copyright IBM Corp. 2003, 2010.

II. ARCHITECTURE OVERVIEW
IBM Cognos Real-time Monitoring can access a wide variety of operational data sources, such as
transactional databases via scheduled JDBC queries, Messaging sources such as MQ Series and Java
Messaging Service, and Web Services sources via either push or pull approaches.
The key benefit of the Real-time Monitoring architecture is the embedded in-memory streaming data
store. This data store aggregates pre-determined information on the fly from data in flight sources. This
allows end users visibility into transactional environments without the burden of ad-hoc analysis placed on
these operational systems. Every end user analysis, drill-down, etc is served up by the streaming data
store, and NOT by the original data source. Data extraction to the streaming data store is via a known
schedule or a simple listen to a message queue, thus eliminating operational system performance
degradations.
Licensed Materials – Property of IBM 3
Copyright IBM Corp. 2003, 2010.

III. REAL-TIME MONITORING SERVER CAPACITY GUIDELINES
Capacity is a term often used to refer to an application’s ability to meet performance expectations when
under load. When determining capacity for Real-time Monitoring three categories are considered:
• Data: data throughput, in-memory data, data model complexity
• Users: active user population
• Content: dashboards, monitor objects, reports
1. Server Processor Capacity
For the Real-time Monitoring server processor capacity, we will use the processor licensing metric PVU,
as in Processor Value Unit. This measure allows one to consistently use a single measure regardless of
the type of hardware leveraged. For further information on PVUs, see:
http://www-01.ibm.com/software/lotus/passportadvantage/pvu_licensing_for_customers.html
Also, for how PVUs are measured in virtualization environments:
http://www-
01.ibm.com/software/lotus/passportadvantage/Counting_Software_licenses_using_specific_virtualization
_technologies.html
The PVU measurement is for the server running the Real-time Monitoring application server, which can
be distributed from other components such as the web server and metadata database.
To determine the recommended server capacity for your application, answer the following questions:
1. How much event processing do
you need the server to process?
If this includes a data at rest
source (i.e. database) than treat
each database row as an event
(i.e. 100000 new rows added per
hour = ~28 msgs per sec)
2. How many people would typically
be logged on at once to a Realtime
Monitoring application?
IF… Then use this number of
PVUs in your server…
More than 2000 events
800
per sec
Between 100 and 2000
events per sec
Less than 100 events per
sec
Licensed Materials – Property of IBM 4
Copyright IBM Corp. 2003, 2010.
600
400
More than 500 people 800
Between 200 & 500
people
600
Less than 200 people 400
More than 10 600
3. How many dashboard metrics are
envisioned that have less than
one minute refresh intervals? Less than 10 400
Based on answers to the three questions above, use the closet number of PVUs in the Real-time
Monitoring server to the maximum number of PVUs stated for each question. For example, if you need to
process 80 events per sec, for 100 users, with less than 10 dashboard metrics, the recommendation is
400 PVUs. On a System x M3 server, at 70 PVUs per core, you could start with 1 hexa core CPU

(6X70=420 PVUs) and be slightly over the recommended 400 PVUs. This will also give you room to grow
with another processor slot if the event rate increases in future.
As another example, if you need to process 150 events per sec, for 100 users, with less than 10
dashboard metrics, the recommendation is 600 PVUs. On a Linux for System z9 server, at 100 PVUs per
IFL (Integrated Facility for Linux), you could start with 6 IFLs and be equated to the recommended 600
PVUs.
Real-time Monitoring has been benchmarked for event throughput up to 15,000 events per sec. Actual
processing performance depends on the implementation. For use-cases needing event throughout
beyond this level, customers should inquire about the Infosphere Streams product that can be deployed
in conjunction with Real-time Monitoring.
2. Estimating Memory Requirements
IBM Cognos Real-time Monitoring maintains data in high-speed RAM, using an in-memory streaming data
store, an analytics engine and cache. The amount of streaming data being monitored per second and the
amount of total data held in memory impact the amount of memory required by the in-memory data store.
The complexity of the data model affects both RAM and CPU utilization, particularly when computing
measure values. For example; some statistical functions such as mean or standard deviation may require
holding a data population in-memory in order to quickly present results. How much is stored in memory is
determined by the dimensionality and time period associated with the measure. Memory requirements
required to select an appropriately sized Real-time Monitoring server can be estimated by looking at
requirements for events, lookup tables, views & cubes, streaming data windows, active users, and
content. However, the best method of estimating memory usage is to leverage a proof of concept to see
actual memory usage for a given use-case. Since this is not always feasible, the sections below are for
information purposes only, and the summary section guidelines only. We recommend even for the
smallest deployments, 32 Gb of RAM be the entry level used. Ensure whatever environment is chosen,
both memory and processor capacity can be scaled as your system requirements grow.
2.1. Event Data
There are two ways to bring data from external data sources into Real-time Monitoring; by defining data
streams and by creating lookup tables.
Data Stream definitions do not have a significant fixed memory footprint, but they do use memory and
CPU as they are being processed. Memory consumption for data streams varies based on event load and
the frequency of event feeds. The memory requirements for a single event can be estimated based upon
the raw data size coming into the server. Real-time Monitoring allocates and releases memory as
needed to process these events in real or near-real time.
Memory requirements for events is estimated as the sum of the raw data size for all events per
second that will execute simultaneously during the busiest processing window. For example; if
you will never have more than three events executing at the same time – then the memory
requirements for events can be estimated to be the sum of the raw data feed size for those three
events.
Example: You are monitoring 3 event streams. At the peak period, the streaming flow may be
estimated as follows:
• Event Stream 1: 450 bytes per event with 3 events per second = 1,350 bytes per second
• Event Stream 2: 280 bytes per event with 1 event per second = 280 bytes per second
• Event Stream 3: 30 bytes per event with 10 events per second = 3,000 bytes per second
• Total streamlining data: 4,630 bytes per second
Licensed Materials – Property of IBM 5
Copyright IBM Corp. 2003, 2010.

2.2. Lookup Tables
Lookup tables also increase memory requirements and their impact on memory utilization is greater if prefetch
is used or if lookup tables are configured with long in-memory retention times. The pre-fetch option
causes Real-time Monitoring to load lookup table data into cache memory and is implemented in some
scenarios to optimize performance. Without pre-fetch, lookup table data is loaded into memory as needed
and memory utilization is controlled though configurable table load and in-memory retention parameters.
Memory requirements for lookup tables can be estimated as the sum of all data to be loaded into
memory at one time. This includes all data for tables using the pre-fetch option as well as the
maximum amount of lookup table data to be held in memory at one time (based upon in-memory
load and retention settings).
Example: You have 15 lookup tables defined in the application. An example lookup table could
be made up of two columns; column 1 being a 4 byte numeric ID, and column 2 being a string of
30 2-byte characters. This gives us a row size of 64 bytes. Each look up table has an average of
20 rows. 8 tables use the pre-fetch option.
• Average size of a lookup table = 64 bytes * 20 = 1,280 bytes
• Minimum estimated RAM (pre-fetched tables): 10.2 KB
• Maximum estimated RAM (all tables): 19.2 KB
2.3. Views & Cubes
Once data is brought into Real-time Monitoring through either data streams or lookup tables; views and
cubes can be created to support analysis activities.
Views generally have lower memory requirements than cubes - unless they are used to maintain raw
event data in memory. Only result sets are maintained in memory for views and these results sets are
updated incrementally – thereby reducing the overall memory utilization for views.
Memory requirements for a view relies upon how data is grouped and what attributes are used in the
view. More granular the attributes result in more data being maintained in the view, which in turn results in
larger memory requirements. Memory requirements will still be less than the size of the raw data as the
view aggregates the raw data based on the defined grouping.
The memory utilization requirements for a view can be estimated by analyzing the size of raw
data, and how it will be used – the level of detail for attributes and grouping to be used.
Memory requirements for cubes in Real-time Monitoring are driven by the number of dimensions in the
cube and the size or granularity of data for each dimension. For example, a cube with a dimension
tracking time at the granularity of seconds will result in a larger amount of data than one using minutes or
hours. Since cubes are maintained in memory, a larger data size for cubes translates into larger memory
requirements to hold the cube. Future requirements for cube growth should be taken into account when
estimating memory requirements.
Similar to views; the memory utilization requirements for a cube can be estimated by analyzing
the size of raw data, and how it will be used – the level of detail for attributes and grouping to be
used.
2.4. Time-Based Windows
Real-time Monitoring provides the ability to monitor collections of streaming data events through timebased
windows that can be defined based upon a number of events or a collection of events within a time
period. Time-based windows are defined as part of the view and cube creation process.
The estimated memory required for a time-based window can be based on the level of detail (or
granularity), the kind of calculation being computed, the number of unique groups in that window, and the
size of the window in time. The type of window being implemented also has an impact upon memory
Licensed Materials – Property of IBM 6
Copyright IBM Corp. 2003, 2010.

utilization. Windows can be either sliding or tumbling; sliding windows have a fixed size once full, whereas
tumbling windows may grow and shrink as the window tumbles and fills again.
The memory requirements for a time-based window can be estimated by considering the
window’s size, type, and granularity.
3. Estimating Active User Requirements
As the Real-time Monitoring dashboard objects actively monitor changes in data; each user accessing a
Real-time Monitoring application is considered an active user. As the number of active users requires
both some CPU and RAM, the number of requests that can be handled by a single model is limited by the
hardware configuration. The summary table which follows this section identifies the anticipated user load
that could be supported by each model.
Active Real-time Monitoring users add to memory and CPU requirements as they create dashboards, and
perform analysis activities, resulting in queries that are created at run-time with the Real-time Monitoring
server. The server caches user queries and results, keeping them in memory and expiring them as part of
normal memory management functions.
Active users are defined as the total number of users that are expected to be actively utilizing
system resources (such as RAM and CPU) at any given time. In short, all users simultaneously
logged into Real-time Monitoring dashboards.
4. Non-production Environments
The sizing requirements in this document primarily relate to production environments and requirements
for these situations. For non-production environments, ideally you will size a test/development
environment similarly. However, if the test/dev environment is under much less load, the server CPU
capacity could be reduced as per section 1 according to the data throughput needs of the non-production
data sources. Also, recommended minimums in section 5 could be reduced in half (e.g. 400 PVUs in
production could be 200 PVUs for non-production) if processing speed and user performance is not
important.
It is important that memory sizings for non-production environments match the production environments,
as the same implementation model must run in the non-production environment. Trying to save nonproduction
environment dollars on memory will only lead to testing and development headaches later.
Any non-production staging environment should always mimic the production environment in both
memory and CPU capacity. This is also true for disaster recovery environments, which are included in
the production licensing for active-passive deployments.
Licensed Materials – Property of IBM 7
Copyright IBM Corp. 2003, 2010.

5. Summary
This table identifies recommended system requirements for typical Small, Medium and Large
deployments. If your application would function in the upper limits of several areas for a given
configuration, then you should consider moving to the next level of deployment. These are guidelines
only. Ensure the environment chosen is scalable as much as possible in terms of CPU processing
capacity as well as addressable memory.
Specs
Users
Installed RAM
(scalable to 128 Gb
for all)
CPU (PVU
measurement)
Average # of active
users
Small Medium Large
32 Gb 64 Gb 128 Gb
As per
Section 1
(400 Min)
As per
Section 1
(600 Min)
As per
Section 1
(800 Min)
100 300 500
IV. REAL-TIME MONITORING CLIENT CAPACITY GUIDELINES
The Real-time Monitoring client runs either Internet Explorer or Firefox, and is processing dynamic data
refreshes provided by the server. Thus the demands on the client environment are much higher than ondemand
refresh type BI applications.
It is recommended the client system have processing capacity of at least one (preferable two) dual-core
x86 Intel chipset. In addition, the client system RAM should be at least 2 Gb as use of client-side caching
is leveraged for real-time performance.
Licensed Materials – Property of IBM 8
Copyright IBM Corp. 2003, 2010.