I’ve got a dashboard which eventually will hold op 16-20 BIWS connections.
(I cannot re-model this data to lower this number)
From my experience I know this will going to kill performance on displaying the dashboard when opening.
even when the BIWS is set to GetLatestDocumentInstance
the scheduled WebI’s only contain the most necessary data and are very small <100Kb
even when the datasets transferred to the dashboard are not bigger then 5 columns and 100 rows (so less then <1Kb data)
It will take AT LEAST more then 1 minute to transfer all the (scheduled) data in the dashboard (when you open it)
I cannot delay the refresh of some of the BIWS since all the data used is right in front of the first screen which you see when you open the dashboard.
So they have to be refreshed aspap when the users open the dashboard.
Is there a way to improve this performance?
I’m thinking of the following:
are there CmC /TomCat settings which you can tweak so the retrieval process of the BIWS is faster?
Has anybody used the XML connection in SAP Dashboards to a local XLS file (which is scheduled and saved to a local directory by BILaunchpad). Is this faster?
A1: Maybe but I think they probably are all optimized
A2: No I don’t think that would be faster because your LOAD time issue id due to number of connections that are complied and executed and NOT a data issue since as you claimed it is less than 100 rows
A1: They’ve never been changed since the default installation… There must be a way to speed up the process of dealing with multiple BIWS’s at the Cmc.
Which cmc servers (services) are involved in dealing the BIWS? Obviously the WebintelligenceProcessingServer and what else?
A2: I agree the number of connections is the problem, but I thought the problem was in connecting with the Cmc which caused the slowy-ness. And if the XML’s are processed locally (without Cmc connection) they might be quicker
We did discover one trick that can speed up the processing. If you are using enterprise authentication with service accounts (e.g., DashboardUser) to connect, use multiple accounts. So set up your first five connections (we found five to be our optimal break point) to use DashboardUser1, the next five to use DashboardUser2, etc.
BOXI’s multi-threading algorithms spread the load from multiple users differently than many threads from a single user. You may get better performance this way.
It didn’t help us a lot, but if you are in the “every second counts” mode, it may shave a couple off.