Regular user (Load to Cube) slow

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Regular user (Load to Cube) slow

      Hi there,

      initially we had the admin user in the etl connection to jedox.
      Since we all know that having admin user do batch jobs is bad, I changed this to a user only for etl Stuff (new user).

      Now the peculiar thing is that with the admin user the load of 100k lines into the cube looks like this:

      Source Code

      1. 2015-03-12 07:04:32 INFO Sending load request to Olap Server
      2. 2015-03-12 07:04:35 INFO Records loaded to Cube: 2800000
      3. 2015-03-12 07:04:36 INFO Sending load request to Olap Server
      4. 2015-03-12 07:04:39 INFO Records loaded to Cube: 2900000

      and the same thing with the "ETL user"

      Source Code

      1. 2015-03-12 07:22:19 INFO Sending load request to Olap Server
      2. 2015-03-12 07:23:01 INFO Records loaded to Cube: 1200000
      3. 2015-03-12 07:23:01 INFO Sending load request to Olap Server
      4. 2015-03-12 07:23:44 INFO Records loaded to Cube: 1300000

      looking at the time tag it's 3 seconds for the admin and 40 to 45 seconds for the non admin user.
      Maybe someone can chime in and explain this for me?

      greetings from Austria
    • Hi jjunek,

      do you have more information about these non-admin authorizations?

      I consider it dangerous to use the admin group for the etl user, for instance if you want to be sure that nobody overwrite a slice by launching an etl job by error then you can't do it using the admin group to laucnh etl jobs... know what I mean?


      Post hoc, non est propter hoc
    • Hi laloune
      you have to find balance between performance and level of details you control rights on.
      One extreme is to load data as admin for fastest process typically used for etl loads.
      Second extreme is to use rules to calculate per cell access rights, typically used for manual writebacks.
      You cannot have fast load while using detailed dynamic access rights.
      For preventing of overwriting some data you can use locking functionality. But it will also slow down etl loads including admin users.
      Depends on type of etl jobs you are starting and who can run it and how the source data looks like. Daily incremental loads of Actual will not collide with your older Actual or current Plan data for example.

    • Hello everybody,

      jjunek wrote:

      Hi DataPhi,

      sure there is a authorization for non-admin users that can slow it down. More complex the right restrictions are longer it takes. You can try to make your etl user member of admin group.

      as of yet, there were no restrictions to dimensions at all for this user, what i gather from this is, use the admin for the etl jobs.
      If the difference were some few minutes I would prefer the security over the performance but 5 Minutes compared to 21 per job is unfeasible.

      Thank you for the information!