2 Replies Latest reply: Mar 3, 2016 5:55 AM by Janusz Twardziak RSS

    Pre-caching exercise - Running JMeter task against an app with the Initial Data Reduction option switched on

    Janusz Twardziak

      Hello Qlik Scalability Group!

       

      I'm working with an application containing Section Access. The Initial Data Reduction option is switched on.

      Now, let's assume there are two users: User1 and User2.

      Situation description:

      1. When I open the app with User1 via web browser and make any selection then when I repeat exactly the same steps with User2 I can see the cache is being used.

      2. When I run JMeter task (via ScriptGenerator from the QlikView Scalability Tools v1.0) against User1 and once finished open the app with User1 then I can notice the cache is used. However if I open the app with User2 and make a selection that was a part of the JMeter task run by User1 then the cache is not used.

       

      Would you help to figure out why in the second scenario the cache is not used, please?

       

      Environment specification:

      QlikView version: QlikView 12 IR

      Web browser: Chrome

       

      Best regards,

      Janusz

        • Re: Pre-caching exercise - Running JMeter task against an app with the Initial Data Reduction option switched on
          Lars Skage

          Hi, Janusz.

          There are many layers and unknown in your question so I'll give a general, simplified, response to how the cache works.

           

          The cache is a storage of previous performed calculations. It is shared in a global cache so all users can benefit from it. The cache does not care how correct traffic was generated, who you are or how you access as long as the data and the "task" to perform is truly identical. The cache is server side.

           

          ALL calculations will be stored in the cache.

           

          There are mainly two things in the cache and that's the state exactly describing the data used and the resulting matrix of columns and rows. They are identified by hashes that are unique for what they represent. This is used when retrieving something from the cache.

           

          To my knowledge there's only one exception when retrieving something from the cache and that's when an object is using a calculated dimension with more than one field.

           

          Section Access will reduce the chance of two users requesting the exact same data. Each user will get their "un-clear:able" selection that determine their slice of the data.

          Asking for the exact same data, with an object with the same properties as already stored will be retrieved from the cache.

           

          How you authenticate and handle the simulated section access might affect things. You need to secure authorization, section access-login and the actions performed. I would use the Session- and Audit-logs to validate what the users select. If that doesn't help, then I would use the Tree-view in JMeter UI to look at the traffic generated by the simulation.


          The only time something is purged from the cache, is when the qvs.exe process reach the WorkingSet-low level. Then a prioritization mechanism will decide what items to purge.

           

          Sorry that I can't give you more precise answers to your problems but it is quite far from what I've experienced. When something similar has happened to me, then the solution was securing the suggestions above and realizing where the differences are.

          The normal troubleshooting technique of "isolate and compare" and "build from the ground up" is the safest way, not always the quickest but most often it is...

           

          br

          /lars