performance very large frameworks

[blom0344]

Due to technical reasons we are trying to store our whole datawarehouse model within 1 framework. We're talking about hundreds of tables/views and perhaps over thousand objects.
At fasttrack course I was told that there is a direct relation between the size of the framework and the time it takes to load it when one wants to create a new report.

Can anyone comment on this? Experiences?

[COGNOiSe administrator]

The FM Model is an XML document so performance of FM will largely depend on how powerfull your development machine is. For large FM models I'd definitely recomend using a workstation (like the DELL Precision or something similar) with fast CPU and large RAM, over say a Tablet PC.

[blom0344]

Okay, that makes sense. However, some of our clients may want to create reports themselves and I am just a little concerned how performance will be if - in this case - a new report is being created with report studio.
To be honest, I have always used BO full clients for reporting and compared to that report studio is very slow indeed. So, I am trying to make the transition from BO full-client to Cognos Web reporting ;)

[COGNOiSe administrator]

The beauty, and occasionally the weakness of CRN/C8 is that it is web-based. So you will have to beef up those developers' workstations, I'm afraid.

[MFGF]

Hi,

I fully agree with all that's been said about the performance of the modellers' workstations, but are we talking at crossed purposes here?  The question seems to be asking about the impact on report performance of using very large frameworks in FM.  The performance of a report in terms of metadata loading is dependent upon the contents of the published package, not the size of the overall framework in Framework Manager.  You may well have a project in FM spanning thousands of tables, but if the published package spans just ten of them, then the package should in theory be quick to load.

It's also worth bearing in mind that C8 and ReportNet will cache metadata defined in the package into Runtime Metadata (RTM) files where possible.  If the package is very large, then it may take a while to create the RTM file on initial load, but thereafter it should be much quicker.  This assumes of course that the metadata can be cached in the first place - if not then more time will be taken performing callbacks to the data source to determine the metadata structure.  Common things in Framework Manager that may prevent metadata caching later on are modification of the SQL in a data query subject, addition of calculations or filters to a data query subject, etc.

Bottom line is that the framework may be huge, but if the modeller is careful and makes sure that caching can occur and that the packages are as lean as possible, then metadata performance when writing/running a report should be fine.

MF.