6 Replies Latest reply: Nov 22, 2012 11:21 PM by drakitine RSS

    The effects of "leases" on the read-performance of Replicated Caches

    902449
      Hi all,

      Whilst doing some Profiling on our code, I noted that (in some cases) much of the time taken to "get" from a Replicated Cache is spent on acquiring a Lease. My understanding of the Lease Model is somewhat limited to the following piece of documentation, so apologies if I'm asking ignorant questions:
      [http://download.oracle.com/otn_hosted_doc/coherence/341/com/tangosol/net/CacheFactory.html]

      Is there any further explanation on how this works? In particular, I'm wondering why Coherence would need to obtain a lease on a simple "get". My underlying data is read-mostly, write-rarely, and a low retrieval time is very important to the application. Is there any way of turning this off, and would it ever be advised?

      Thanks.

      Edited by: 899446 on 19-Nov-2012 04:38

      Edited by: 899446 on 19-Nov-2012 04:39
        • 1. Re: The effects of "leases" on the read-performance of Replicated Caches
          robvarga
          899446 wrote:
          Hi all,

          Whilst doing some Profiling on our code, I noted that (in some cases) much of the time taken to "get" from a Replicated Cache is spent on acquiring a Lease. My understanding of the Lease Model is somewhat limited to the following piece of documentation, so apologies if I'm asking ignorant questions:
          [http://download.oracle.com/otn_hosted_doc/coherence/341/com/tangosol/net/CacheFactory.html]

          Is there any further explanation on how this works? In particular, I'm wondering why Coherence would need to obtain a lease on a simple "get". My underlying data is read-mostly, write-rarely, and a low retrieval time is very important to the application. Is there any way of turning this off, and would it ever be advised?

          Thanks.

          Edited by: 899446 on 19-Nov-2012 04:38

          Edited by: 899446 on 19-Nov-2012 04:39
          Hi,

          If I correctly remember this peculiarity, in Coherence replicated caches the existence of an acquired lock for a key or an InvocableMap.process() method for a key (which acquires a lock) blocks a concurrent get for the same key. Can it be possible that in those cases you see, this is what is actually happening?

          Best regards,

          Robert
          • 2. Re: The effects of "leases" on the read-performance of Replicated Caches
            902449
            Hi Robert,

            No, we never lock or run Entry Processors against these caches. We only ever putAll() and get(). I've included some profiling output as an example of my findings:
            9,996 µs - 100 inv. com.myproject.MyCacheDao.get
            + 9,446 µs - 100 inv. com.tangosol.coherence.component.util.SafeNamedCache.get
            ++ 8,825 µs - 100 inv. java.util.Map.get
            +++ 8,782 µs - 100 inv. com.tangosol.coherence.component.util.CacheHandler.get
            ++++ 8,728 µs - 100 inv. com.tangosol.coherence.component.util.CacheHandler.getCachedResource
            +++++ 7,182 µs - 100 inv. com.tangosol.coherence.component.util.CacheHandler.getLease
            +++++ 1,025 µs - 100 inv. java.util.Map.get
            • 3. Re: The effects of "leases" on the read-performance of Replicated Caches
              drakitine
              try to repeat your test with override like this -
              <coherence>
                <cluster-config>
                  <services>
                    <service id="1">
                      <init-params>
                        <init-param id="lease-overflow">
                          <param-name>graveyard-size</param-name>
                          <param-value>0</param-value>
                        </init-param>
                      </init-params>
                    </service>
                  </services>
                </cluster-config>
              </coherence>
              • 4. Re: The effects of "leases" on the read-performance of Replicated Caches
                902449
                I've done some provisional testing using the config you've supplied, and so far the results are promising - the amount of time taken to acquire the lease has dropped dramatically!

                Could you tell me:

                1. What does this configuration do?
                2. Where is the official documentation describing this?
                3. What possible issues could this cause?
                4. Is this configuration supported for Production use?
                • 5. Re: The effects of "leases" on the read-performance of Replicated Caches
                  902449
                  Any chance of an update on this? I'd really like to put this into Production, but can't really do so until I understand what this change does.

                  Thanks!
                  • 6. Re: The effects of "leases" on the read-performance of Replicated Caches
                    drakitine
                    It changes internal implementation of a lease map to a simple HashMap, and yes, it is perfectly fine to use it in production.