Cognos 8 is a sophisticated set of products and capabilities. Sizing the architecture can be a challenging task requiring knowledge of expected system overall workload. As a result, expect some iteration on the architecture to customize it appropriately to your requirements.
There are many factors to consider when determining the virtual hardware specifications for your cloud instances. The combination of these factors influences the amount of load the system can handle, which may vary from time to time.
In a typical data center environment, you must plan for peak loads, so IT resources are frequently underutilized. Thanks to the dynamic nature of cloud however, peak loads are easily accommodated as needed so the new planning standard becomes the average capacity needs; resources can be added dynamically when required and removed at any time when the load is reduced.
In this article, we provide some general guidelines and architecture recommendations to support a large-scale deployment of Cognos 8 onto the IBM Cloud.
To address performance and scalability practices, we'll look at:
- User community and geographic distribution of users.
- Application complexity (the various tiers).
- Post-deployment considerations.
For more on installing and configuring Cognos in the IBM Cloud, see the rest of this series and the Cognos site (Resources).
User community and geographic distribution
For the context of this article, a user of your Cognos solution will be categorized into three different user groups:
- Named: All users registered to the system.
- Active: Named users currently logged onto the system but not necessarily in the process of submitting a request or waiting for one to finish (say like a user reading a report).
- Concurrent: Active users that are in the process of submitting a request or waiting for one to finish.
Based on IBM's experience with large-scale deployment, a commonly observed ratio among these users is 100:10:1, respectively (with only 1 percent being a Concurrent user at any one time). This means for each 100 Named users, 10 users are Active and 1 user is in the process of submitting or executing a request.
Notice that same systems require much higher or lower concurrency rates. In most cases however, concurrency rates do not exceed 5 to 7 percent, even during peak hours. When calculating system load, only Concurrent users need to be considered.
Another important factor to consider is the geographic distribution of the user community which will also impact the average and peak load of the system. Variations in the time zones of your users can result in surprising impacts on the daily patterns of load on your Cognos deployment. If you have a comparable production server in place, measuring its actual load patterns over a period of time can go a long way towards getting accurate concurrency rates and is highly recommended.
In addition to considering the requirements of the average number of Concurrent users, the complexity of your application also influences the resources required. For example, reports that require complex database queries or advanced formatting will require more report-processing capacity. This means the number of reports that can be served at any given time will be reduced. Supporting the same number of Concurrent users in these types of application will require larger system capacity.
Now we'll look at some practices to apply to keep scalability and performance at the right balance for the web server tier, the application tier, and the content-management tier.
Web server tier
For planning purposes, we suggest that an environment should be sized to accommodate 50 Concurrent users per modern CPU, regardless of the user role.
However, there are two factors that will affect the estimation of the hardware requirement to support average load on the web tier:
- First, if Secure Sockets Layer connectivity is used there should be a reduction in the estimated number of supported Concurrent users.
- More importantly, also consider the failover requirements of the solution and allocate extra CPU power to fulfill your high availability requirements.
Planning for report and query processing is the most important consideration if you're looking to supply a highly performing Cognos solution. Report and query processing will be influenced by both the number of Concurrent users as well as by the complexity of your application.
For interactive reporting, a general guideline is to assume a starting point of two interactive report processes per CPU, each with four report execution threads. This translates into eight concurrent interactive reporting requests per physical CPU.
2 report processes/CPU x 4 report execution threads -------------------------------------- 8 concurrent reporting requests/CPU
Because of the large data volumes associated with batch report processing, a general guideline is to assume two batch report processes per CPU, each with two report execution threads. This translates into four concurrent batch reports executed simultaneously per physical CPU.
2 batch report processes/CPU x 2 report execution threads ------------------------------------------- 4 concurrent batch reporting requests/CPU
Keep in mind that these are the general assumptions based on IBM's experience; they may vary from solution to solution. When calculating the required resources for a Cognos solution in the cloud, use these general assumptions along with expected daily average number of Concurrent users to determine the cloud hardware requirements.
Cognos 8 is designed with scalability in mind. Adding more Cognos application servers during peak hours to handle heavier system loads is as straightforward as instantiating new instances of the server into the system. These newly added server instances will share the system load automatically and almost immediately. When that processing power is no longer required, the servers can just as easily be shut down and removed.
Content Manager tier
The performance of the Content Manager is influenced substantially by the number of objects in a package or folder and the security associated with the objects. For example, if a folder or package contains a large number of objects, user permissions for each object must be verified when a user with limited privileges accesses it to ensure that security rules are enforced. If there were fewer objects in the folder or if the entire folder were not secured, far fewer resources would be required.
IBM's experience with average usage patterns suggests that one Content Manager CPU should be allocated for every four report-processing CPUs; however, if your application requires more Content Manager processing capacity, then doubling the Content Manager CPU allocation would be reasonable.
Finally, because 32-bit JVM's are limited to a 2GB memory addressing space, IBM recommends the Cognos Content Manager be deployed onto a 64-bit operating system. A 64-bit configuration is strongly recommended for large-scale deployments.
These recommendations are only a general guideline based on our experience on average usage patterns. System monitoring is vital as resources are deployed and often leads to configuration adjustments. Additional resources may be required depending on failover and load balancing requirements.
Look for more information on running Cognos on the cloud at the Cognos site and on developerWorks (Resources).
- For more in this series, see "Moving from a single- to a multiple-image topology."
- Find more information about Cognos Business Analytics.
- Check out other IBM Business Analytics software.
- The Cognos Proven Practices team delivers documentation of practices built from real-life customer experiences.
- The Redbooks draft "IBM Smart Analytics Cloud" details a lab implementation of a smart analytics cloud.
- In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
Get products and technologies
- Join a cloud computing group on My developerWorks.
- Read all the great cloud blogs on My developerWorks.
- Join the My developerWorks community, a professional network and unified set of community tools for connecting, sharing, and collaborating.