Multiple Cognos instances in one server (Performance Tuning)

1. Multiple Cognos instances in one server(Performance Tuning) -Suraj Neupane (Consultant @ Denver Water)

2. Performance Tuning • Most important aspect after data integrity (sometimes before). • Various approaches to tuning: • Tune parameters in Cognos server. • Report/model: Prompts; Union; Calculations; graph/text; drill etc. • Use tools and features within Cognos: schedule/cube/shared drive. • Database/ETL: Aggregate tables; other apps against the same db. • Use features from third party apps: Tidal scheduler, BSP etc. • Hardware upgrade: License; cost. • Application upgrade: License/deprecated/new features; training. • Add instances of application. (Results may vary). • This presentation focuses on adding reporting instances. • Not multiple instances of different versions such as C8 and C10. • It’s opposite of distributed installation.

3. Report Service Tuning Things to keep in mind depending upon setup: • High Affinity connections: 1 per process • Low Affinity connections: 4 per process • Maximum number of processes: 2 per processor Maximum RAM two instances can use with 4 CPU: 20gb 2 X BIBus = 4gb X 2 for RS = 8gb 2 X BIBus = 4gb X 2 for BRS = 8gb Java processes: up to 2gb each. Set peak periods (eg. 7am-6pm). (Note: Refer to Administration guide for other tuning settings).

4. Cognos Architecture

5. Services in a dispatcher Each dispatcher adds associated Cognos services as mentioned below:

6. Expectation from additional instances • Work around OS Stack memory constraints of 2gb per running process. (Note: system needs enough physical memory cache for this method) • Take the most out of underutilized resources. • Load balance requests with multiple dispatchers. • Report level processing with additional Cognos services. • Overall, improve performance utilizing existing resources.

7. Analyze current setup • Licensing Model: Named vs PVU. • Named licensing model (old) can use additional hardware that is a better option than adding instances. • Adding instances is recommended for PVU licensing model. [Note: Always consider license compliance before changes.] • Current application load on server • Current CPU and RAM utilization.

8. Analyze current setup… • Is current setup working as expected? - Create performance log files and monitor CPU usage trend. - Do not implement if the usage is consistently over 80% - Check logs for errors, monitor performance. Server errors appear even after tuning as per IBM recommendations. One of the famous error is ‘Server did something wrong’.

9. Analyze current setup… • Check background jobs for ‘Pending’ status during scheduling window.

10. Implementation Process • Install ‘Application Tier Components’ for new instances in new directory. Do not install ‘Gateway’, ‘Content Manager’ and ‘Cognos Content Database’.

11. Implementation Process… • Configure Cognos services for 2ndinstance: • Configure log server, shutdown and dispatcher URI with different port numbers than original Cognos configuration. • Apply all the custom modifications to the 2ndinstance (Important!). • Stop original Cognos services and add dispatcher URI from 2ndinstance. • Save configuration and start both instances of Cognos services. • Tune both instances same (logging, tuning etc.) in Cognos administration. • Restart both Cognos services after tuning is complete. [Note: Refer to Administration guide for additional details]

12. Verification When the implementation is complete, multiple dispatchers with different port numbers exist in Cognos administration window.

13. Verification… How to verify if the load balancing is working? • Run reports and check requests received in both dispatchers. • The report service requests should be divided between the two dispatchers. The numbers may not be exactly same but should be close enough. Example: After 1.5 months: • Monitor performance as the results may not be as expected that requires additional tuning.

14. Results from our implementation • Existing reports/jobs/schedules are working as before; some have better performance. • ‘Report server is not responding’ error reduced. • Job schedules do not get stuck in ‘Pending’ status. • The server has become more stable and efficient. - Less restarts due to jobs not pending anymore.

15. Dependencies with external apps Analyze the implication for external applications such as Tidal scheduler, BSP Metamanager etc. before and after implementation. - Number of job services/connections configured in external applications may need modification due to new tuning parameters in Cognos dispatchers.

16. Summary • Check IBM license before any work on Cognos server. • Analyze existing setup for bottleneck. • Add instances of reporting services to allow better use of underutilizedhardware. • Monitor performance after implementation. • Experience may vary depending upon server configuration/resources.

17. Disclosure and Q & A • Implement this method at your own discretion. • If you have similar setup, please provide configuration settings that worked best. • Feedback/comments? Feel free to email me: Surajneupane@gmail.com Suraj.Neupane@denverwater.org 720-432-8842 • Find me @ Cognoise, Experts-Exchange, ittoolbox& IBM Cognos forums. … Thank You …