Performance of portal (dashboards) in Cognos Connection

[flytrap]

Wasn't sure if this is the correct location for this inquiry, but it has to do with descending performance when adding reports to a page.

We have an Executive dashboard "landing page" with 3 columns of Cognos Viewers and a couple Cognos Navigators.  Total of 7 reports.  Some of the reports are not complex some are, but the reports don't seem to be causing all of the delay.  Each report probably comes back within a couple seconds.  However, we are seeing a long delay before the page even begins to be rendered after clicking the page or portal tab for the dashboard.

We have performed a load test on this system and the sheer number of threads and context switches on the processors is mind numbing, even when simulating 3 people hitting the dashboard simulaneously.  I believe we have implemented IBM/Cognos best configuration practices based on the number of processors/cores available to the application.

For example I created several reports than are just "select dummy from dual;" (we have a junk package that consists of just 'dual' in Oracle) and therefore displays only 'X'.  When I add one or two of these to a page, the rendering of the "dashboard" page is instantaneous.  However, by the time I've added 4 -6 of them, rendering performance dropped noticeably (like 15-30 seconds after the click before the page looks like it is doing anything).

Is this a known issue to anyone?

I suppose the next step is to watch our database performance real time when no one else is on the system to see if there is a delay in Cognos hitting the database, then we could blame it all on Cognos architecture   ;D

BTW, security is LDAP single sign on, with object security based on users assigned to groups set up in the Cognos namespace.

[RobsWalker68]

Hi,

Hopefully you are on 8.4 or later.  Before you investigate the database what are the system metrics telling?  They may give you a clearer indication of what is possibly going on with regards to resources and queue times etc

Rgds

Rob

[T4FF]

We have had performance issues with Cognos, but I think we've nailed it.

One of the main areas for improvement is ensuring that as many reports as possible are produced (on schedule or otherwise) so that the dashboard is just using static data.  If you consider what the dashboard will do - 7 reports need running simultaneously.  Depending on your config, these may end up queueing.

We found performance improved dramatically where dashboard was picking up saved reports where possible.  There is a catch though - there is a setting on the report (Properties > Report > Advanced options) called Enable enhanced user features in saved output versions that MUST be ticked or the dashboard will still attempt to run the reports.

This may not be your issue but thought I'd share my experiences as we were having serious performance issues.  It isn't great to be fair, everything from isntalling it to using it, Dashboard feels a rushed product, but it's a lot better than it was when we first started out.

[flytrap]

Frankly the system metrics are telling me that Cognos is not scaling very well as load testing adds simulataneous users.  We have adequate hardware (dual quad core Zeon processors with 8GB RAM) and have only simulated 12 users hitting Cognos concurrently.

Caching of reports does help, but that still does not explain the rendering delay of using a multi-report page (dashboard portal).  And in some cases we are interested in real time!  :D

If anyone has time, I'd ask you give it a shot and report here.  make a temp directory in CC, and create a page that will hold several Cognos objects (viewers/navigators).  Then create several dummy reports that do very little (test1, test2, ... test(n)).  Then add these reports one by one to the page running it each time.  Note the render time each time a report is added. We found the first couple are instant, but time expands subsequently.

We are on 8.4

[smiley]

@flytrap; how many processes are configured for interactive reports, and for scheduled reports?
How many low affinity requests are configured on both?

[RobsWalker68]

Hi,

Is that 12 simultaneous users running the mentioned dashboard report or are you testing with a mix of concurrent reports?

I know 12 concurrent users doesn't initially sound a lot but using the IBM 1:100 ratio that's the concurrency roughly required for a 1200 user system.

Rgds

Rob



 

[RobsWalker68]

Hi Flytrap,

Just a few ideas.  Without knowing your system setup it's hard to offer advice and it's a bit of a stab in the dark but this is how I would approach the issue. Hopefully some of this may be useful.

I've tested a multi-report dashboard and I don't appear to be having any issues.

Test Setup

I created a dashboard with 10 Cognos Viewers accessing a variety of unfiltered crosstabs, charts & lists from 3 different Cognos sample packages and the response time for the presentation of the portal page was under 5 seconds.  After each report addition I made sure I cleared the cache.

There are a few caveats of course:

1. I'm on a single user system, albeit a laptop (Intel Core I3, 4gb ram, Windows 7 64 bit).
2. I'm running SQL Server 2008 in addition to Cognos 8.4.1 on the laptop
3. I used the Go Sales (Query), Go Datawarehouse (Query & Analysis) IBM sample packages.
4. I don't have object security defined in the Framework Model.

This most probably doesn't tell us anything particularly useful about your specific issue just that Cognos doesn't have an issue with a multi report dashboard per-se and that somewhere we are looking at a resource contention issue, be it database or Cognos related.

Process Flow

The workflow from your browser is going to be
1. Gateway to Dispatcher
2. Dispatcher to Presentation Service
3. Presentation Service to Report Service via Disptatcher
4. Report Service to Content Manager via Dispatcher
5. Content Manager to Report Service
6. Report Service to Presentation Service
7. Presentation Service back to browser via Dispatcher and Gateway

If you can get some quiet time on the system then refresh your system metrics, as long as you are not actively using them of course, and see if you can identify any contention issues with the above services when you are running multiple concurrent instances of your dashboard.

For the database: 

Add application context to your SQL so that your DBA can easily identify what is being sent to the database and from what reports.  More information on this is in the Admin & Security Guide.

Stress Test

You mentioned you had stress tested with 3 concurrent users which equates to 21 report requests being received by Cognos but also 12 concurrent which equates to 84 report requests.

If you have a dual quad then I presume the number of interactive report processes is no more than 16 and with O/S and JVM memory requirements a little lower due to the RAM.  Have you noticed any report service queue issues or report service process issues?

As an observation  the amount of RAM compared to the number of report processes you can run that will utilise it seems a little low, although may not be an issue here as you mentioned the reports are fairly straight forward.  Something to review in future perhaps though.

Rgds

Rob

[vkubera]

Hello,
I see Load/stress test was mentioned in this post. I am trying to Load test Cognos 10 Business Insight (Dashboard) with HP Loadrunner. Due to the AJAX based application calls the tool we use is not very supportive.  I am wondering what tool you people have used for your load testing.

Please advise ..

Thanks
Venky