This content has been marked as final. Show 5 replies
Thanks Rahul. The Data Form considerations document is a good one and one I try to adhere to (where possible).
I have under-estimated my form size - it is 117,900 cells, not 11,790.
But still, a form with the same columns is 11,900 cells and opens almost immediately, so I am a bit confused why my form that (granted) is 10 times bigger takes so long to open. I have tried moving the DataSource off to the PoV and this fixes the issue. I think I have a cache setting to correct (or, at least will need to make the single DataSource parent, of 2 members, Store rather than DC).
Increasing the Java heap size (memory setting) in this case will not improve performance. You either have enough or not enough (yields errors)
Forms are built in such a way that they tend to favor rows more than columns (very complicated topic that relates to things like how the form is constructed, and how essbase is queried during that process). People usually only have period or period and something else(Actual & Budget) in the columns.
Put Year in the POV (or page if you need to see other years)
Put account on the rows & suppress missing
Try changing the form so that not so much information is spread across the columns, I can almost guarantee the form will run faster.
Along with Robb's suggestion, you can do the following:
1. Open the form through planning web then check the essbase logs how much time its taking at essbase end, you will find an entry total time elapsed this will give you time taken at essbase end, if this is more, then we can check the essbase caches to make it as low as possible,
2. Do you have many dynamic calc members as well in the from, if that is the case then its wroth increasing the dynamic calc caches.
It's also important to note that not all the performance bottlenecks are caused by the servers, some get stuck on the client. When you open a web form, Planning sends a query to Essbase and in return Essbase sends the result set back to Planning. Planning then pushes the result set back to client along with a form generation java script. Your browser renders this Java Script to HTML and when it's done you see the form open. In many cases, I've seen that Firefox (earlier versions not the latest breed) is much faster than IE for opening forms. That must be because of the difference in the way they handle JS code.
To try out, when you click on the form launch your task manager to check the CPU usage of your browser. If it climbs up to a certain usage and stays there for a long time when you wait form to open, that suggests that the bottleneck is on the client side. If this is the case, you may want to give a try to Smartview which doesn't deal with java scripts or HTML codes but directly utilizes the result set. It might make an enormous difference.