5 Replies Latest reply: Sep 7, 2011 11:34 PM by Alp Burak RSS

    Big Data Form?

    ES_Planning
      I have a form that contains 100 columns of data and has 1,179 rows, so is 11,790 cells. It is taking 12-13 minutes to open and is being run local to the VMs it is based on (I am accessing the apps via RDP).

      I have Entity and a three member DataSource dimension on the row and have Year, Period, Account and Scenario on the columns. Cost Centre and Version are on the PoV.

      In my view, it is more complicated that the average form, but is not massively complex or big. Is 11,790 considered big or excessive? I believe that there is somewhere that we can change a memory or Java setting on the web server to allow large forms to not hang or take so long?

      I am currently testing various limited versions of the form to see if I can find what is causing it to crunch, but am hoping that someone could give me a pointer on changing a standard setting somerwhere or tell me that I am trying to do too much in one place?

      Many thanks!
        • 1. Re: Big Data Form?
          _RahulS_
          How do I Change the Java Options and Heap settings for Planning on Weblogic or Tomcat (Doc ID 744805.1)

          I guess you will like to go through:
          Hyperion Planning Data Form Design Considerations (Doc ID 779502.1)

          Cheers..!!!

          Edited by: RahulS on Sep 7, 2011 10:47 PM
          • 2. Re: Big Data Form?
            ES_Planning
            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).
            • 3. Re: Big Data Form?
              Robb Salzmann
              Hi ES,

              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.

              Suggestion:
              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.

              Regards,
              Robb Salzmann
              • 4. Re: Big Data Form?
                _RahulS_
                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.

                Cheers..!!
                • 5. Re: Big Data Form?
                  Alp Burak
                  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.

                  Cheers,
                  Alp