Lowest performance after upgrading from Cognos 10.1.1 to 10.2.2

[Conqueror]

Hi,
Hoping you could help me...

After an upgrade from Cognos 10.1.1 to 10.2.2, I've noticed a degradation of the performances of the reports, taking twice more time

Context:
We have done an « upgrade » from Cognos 10.1.1 to Cognos 10.2.2, passing from a physical machine to a virtual one which will be hosted in a datacenter

After a study by the technical department, they noticed the RAM is never used more than 10% in the former server hosted Cognos 10.1.1, so they decided to reduce the RAM and the CPU of the new server which host Cognos 10.2.2

Here's the initial architecture, and the new one:

1)   COGNOS

a)   initial architecture

physical environment
CPU : 24
RAM : 48 Go dedicated
OS : Windows Server 2008R2 Datacenter
Version : 10.1.1

b)       new architecture

virtual environment
CPU : 8vCPU dedicated and not dynamic
RAM : 16Go dedicated
OS : Windows  Server 2012R2 datacenter
Version: 10.2.2


2)   SQL (SGDB – Datawarehouse)

a)   Initial architecture

physical environment
CPU: 24
RAM: 48 Go dedicated
OS : Windows Server 2008 R2 Datacenter

b)   new architecture

Physical environment
CPU : 24
RAM : 48 Go dedicated
OS : Windows Server 2012 R2 Datacenter

Solutions tested that did not work: (cognos 10.2.2)
•   Addition of the RAM from 16 to 24
•   Addition of the memory on bm config from 1536 to 2048
•   Several tuning on the settings high affinity and low affinity
•   Addition of CPU from 8 to 10

Observation : A SQL code typed in the former and the new SQL Server takes the same duration

Thanks

[cognostechie]

Was the report specification upgrade done or only an export and import was done between the two versions?

[Francois51]

Just my 2cents because this kind of problems can have many causes so one need to be humble :

I had issues when upgrading from 10.1 to 10.2.1. It was more about stability than performance but anyway here is the thing that worked : I finally ended thinking it was the java heap mangement the culprit as it crashed  randomly. So after a lot of testing I finally tried to reset all the parameters to default in the cognos configuration for the dispatcher and it never crashed again. You can then begin to tune again if needed. I know, it's pretty scary to test in production.

Since you moved from physical to virtual, I guess you've already looked at the I/O on the database server and the application one? What about the gateway? Is it a third machine?  do you have the sames latencies whether it's an html report or a pdf one?
It can also happen that you virtual machine is doing well but the underlying physical host is under heavy load, do you have access to both performance metrics?

It may also be a bug, I guess you can open a service request if it's not done already.

[cognostechie]

Hi -

I don't think there is any bug as lot of companies have done this. Moreover, IBM has declared in their documentation that the reports will become slow after an upgrade and you have to perform the task for report specification upgrade in order to bring the reports back to it's original speed.

VM is also not a problem but the available RAM can cause a problem but that should only be troubleshot once the correct procedure has been followed. That way the chances of finding the problem area increases.

[Conqueror]

Francois > we do a lot of combination with cognos configuration but no results.   - no worries, we are not in production. The I/O is tuned correctly, for the gateway (If I understand what you want to say) we are in IIS 8 and it's tuned correctly again .  We had tested in html, pdf, excel and it's horribly the same. For audit performance, I see the log of 'cogserver' and I notice a latency in the request between cognos and sql server in the new environment.

Cognostechie > The report specification was done.

I notice that in the new environment, Cognos doesn't use with optimum the RAM and CPU. I'm searching how to force the applicative to use it more

[Francois51]

Hi conqueror, I guess you already did the report upgrade as cognostechie suggested? Did you?

Also I had terrible latency when dealing with planing and the solution was to force ipv4. The fact tha ipv4 and ipv6 were by default activated in the network card was the culprit. Once it was forced in ipv4 in the NIC and the cognos configuration there was not any latency left. It's a shot in the dark but easy to test.

[cognostechie]

That's nice to know Francois. Thanks !