This content has been marked as final. Show 6 replies
This is a fairly common issue and you may want to search the forum for other posts.
How many cells (rows * columns) is your simple form? Generally you start seeing some pretty big performance hits on any form > 3000 cells.
The first thing you want to do is see if you can make use of suppress missing data/blocks and have some code create data which is valid for entry on that form.
Next thing is ensure you are using only dense dimensions in your rows and columns with perhaps one sparse dimension. Place the other sparse on page/pov.
Review your JVM memory settings (although if this is an issue with just one user your memory settings won't help performance however may allow multiple users to open the form without crashing planning)
See the post for some other information:
Re: Very large Input form-how to handle
user10998020 wrote:We also encountered web form performance issues when the no. of cells exceeds 2000-3000. We found that under each cell the Hyperion system will issue a SQL query to the metadata database to get the cell content and text attached to the cell. We have requested Oracle team to provide us a hotfix to remove the linkage of the SQL query to each individual cell.
We are using Planning 9.3.1 and while opening web forms in the system which is just a simple form it takes too long time to open it. Can anyone suggest some ways to make opening of the web forms fast.
Number of cells in the form is 1750.
We are just using dense dim rows and combination of dense and sparse in column.
The JVM memory setting is set to 1024M.
I'm not sure about what you said about creating a code to create data which is valid for entry on the form, can you please give some details on it.
I also found a link on Hyperion website where it talks about the slow performance of the web form on dial up connection but I think it should work for others too.
Please let me know what do you think about it. Thanks...
It may not be a bad idea for a few of us to get enhancement requests in asking for better support for larger forms -- seems it has to be a Planning issue as if you do the same type of activity in an Essbase lock/send it's lightning fast.
When you say the form is slow with 1750 cells, is this taking 5 seconds, 10 seconds, 30, 2 min, ...?
I would say anything that's sub 10 seconds for a form that size is pretty normal. How many sparse dimensions are you using?
Unless you do have slow link to the planning server than I do not believe taking advantage of those settings will influence the speed you are seeing as if you were to use only dense dimensions with similar cell size it would be fast which tells me the performance issue is on the planning server side.
Regarding the SQL queries -- I'm not convinced that alone is the reason for poor performance on large forms. I believe it's more how planning communicates with Essbase and handles security of all the dimensions as well.
You should also realize your client (IE/Firefox) will tend to use a lot of memory on large forms -- I've seen it take up to 500mb on very large forms.
In your instance I'm not sure using suppress missing and blocks will help out a lot. The premise is you create data in say the BegBalance Period on a monthly form in the intersections which are valid for data entry with a rule/calc script. You then you turn on the suppress missing option on the form and it will restrict the number of cells which planning pulls from Essbase as well as those cells sent to the browser.
Thats true.. when we are using smart view it renders the form so fast and also Essbase Lock/Send works great, but the bottlenck comes up when we are using IE/Firefox.
The first time I open this form it takes almost 3-4 minutes to open the form but after if I change the page dim the data refresh is pretty fast. We have almost 3 sparse dim in column that are with period dimension.
Whenever I talk to Oracle support about the performance issue with the web forms they always want us to get their infrastructure team to come to us to look into it and they never help on it. If you want we can surely put some tickets for enhanced support for larger forms.
You will find if you remove one of your three sparse dimensions and put it in the Page/POV it will become quite a bit faster and if you remove two of them it will be pretty usable.
It's really a design issue with how Planning JVM speaks to Essbase and/or handles the security on sparse dimensions. If you have a case where they want you to engage their infrastructure team then suggest they just replicate a form like you have on their virtual machines and they should see the exact same performance issue -- make them do the leg work when you can.