Questions about KVM

I have two KVM created through UI.

Key of the 2nd KVM is values of the entries of 1st KVM. For example,

KVM1

==============================

API1 ============>> SLOW_TIMEOUT

API2 ============>> FAST_TIMEOUT

KVM2

============================

SLOW_TIMEOUT =========>> 5000

FAST_TIMEOUT ==========>> 10000

Now I have the literal "API1", I have to get the timeout value.

Do I have to add two KVM policy to get the timeout? Can it be done in one policy?

Also what would be values of the <Scope> and <ExpiryTimeInSecs> tags.

I want to retrieve the values everytime of the proxy execution cause timeout can change.

Will there be performance hit if i call KVM to retrieve value every time of proxy execution?

Thanks,

Krish

Solved Solved
1 2 481
1 ACCEPTED SOLUTION

Yes, you will use two KeyValueMapOperations to retrieve the data you want.

As for Scope and ExpiryTimeInSecs, the values you choose for those settings depend on your use case. I'll refer you to the documentation for further information, but in quick summary:

  • Scope describes the accessibility of the Key-Value-Map store: org-wide, environment-wide, apiproxy-wide or policy. If you have a set of settings that will be commonly used across the org (by proxies in all environments), then it makes sense to use an org-scoped KVM. You may be aware that the Apigee Administrative UI allows you to create KVMs, and to create or edit key-value pairs in those KVMs. The Admin UI today operates only on environment-scoped KVMs ! So if you are creating and administering KVMs via the UI, then you must use "environment" as the value for your Scope in the KeyValueMapOperations policy. KVMs can also be provisioned via an administrative API.... and if you do THAT, then you create them in org scope, or proxy scope, etc. In that case, you may use other values for the Scope element in the policy. I hope this is clear.
  • ExpiryTimeInSecs governs the cache "time-to-live". Regardless whether you use a Put or a Get in a KeyValueMapOperations policy, the value is implicitly cached in the message processor. What it means: the first time a KeyValueMapOperations policy runs (let's suppose we're using a Get operation), the policy needs to read from the KVM store, which is remote and backed by a permanent store (SSD or harddrive). That will take ~10ms or so. The net time that same policy runs, eg, for the next API call, the Get will check the cache. If the cache is warm, then the cached value is returned to the Get, and this will take much less than 1ms. Aside from the wall-clock time saved, caching these reads (Gets) will make a huge difference in scale at high concurrency. By default the ExpiryTimeInSeconds value is 300 seconds, but you can use this element to set it lower or higher. Be careful! If you choose a value of 86400, then run the policy ONCE, subsequent runs of that policy will use the cache for a full 24 hours. Even if you administratively modify the KVM value (for example setting the SLOW_TIMEOUT To 2500 instead of 5000), the KVM Get will still read the old value of 5000, until the ExpiryTimeInSecs elapses. Therefore: if you want to be able to administratively make changes that are "quickly" picked up by KVM/Get, then you should set the ExpiryTimeInSecs to be "relatively low".... Exact meaning of "quick" and "low" are up to you to decide. It could be 10 seconds, 30 seconds,... you choose. If you have o(100) transactions a second, the choice of cache lifetime will not be critical to the performance of the proxy. If you have o(5000) transactions per second, the choice of expiry of the cache will have more impact. In cases where I wanted admin changes to be effective relatively quickly, with low transaction volumes, I use an expiry time of 10-30 seconds. But as always, for performance sensitive systems, the best way to determine the correct setting is to test the H*** out of it.

View solution in original post

2 REPLIES 2

Yes, you will use two KeyValueMapOperations to retrieve the data you want.

As for Scope and ExpiryTimeInSecs, the values you choose for those settings depend on your use case. I'll refer you to the documentation for further information, but in quick summary:

  • Scope describes the accessibility of the Key-Value-Map store: org-wide, environment-wide, apiproxy-wide or policy. If you have a set of settings that will be commonly used across the org (by proxies in all environments), then it makes sense to use an org-scoped KVM. You may be aware that the Apigee Administrative UI allows you to create KVMs, and to create or edit key-value pairs in those KVMs. The Admin UI today operates only on environment-scoped KVMs ! So if you are creating and administering KVMs via the UI, then you must use "environment" as the value for your Scope in the KeyValueMapOperations policy. KVMs can also be provisioned via an administrative API.... and if you do THAT, then you create them in org scope, or proxy scope, etc. In that case, you may use other values for the Scope element in the policy. I hope this is clear.
  • ExpiryTimeInSecs governs the cache "time-to-live". Regardless whether you use a Put or a Get in a KeyValueMapOperations policy, the value is implicitly cached in the message processor. What it means: the first time a KeyValueMapOperations policy runs (let's suppose we're using a Get operation), the policy needs to read from the KVM store, which is remote and backed by a permanent store (SSD or harddrive). That will take ~10ms or so. The net time that same policy runs, eg, for the next API call, the Get will check the cache. If the cache is warm, then the cached value is returned to the Get, and this will take much less than 1ms. Aside from the wall-clock time saved, caching these reads (Gets) will make a huge difference in scale at high concurrency. By default the ExpiryTimeInSeconds value is 300 seconds, but you can use this element to set it lower or higher. Be careful! If you choose a value of 86400, then run the policy ONCE, subsequent runs of that policy will use the cache for a full 24 hours. Even if you administratively modify the KVM value (for example setting the SLOW_TIMEOUT To 2500 instead of 5000), the KVM Get will still read the old value of 5000, until the ExpiryTimeInSecs elapses. Therefore: if you want to be able to administratively make changes that are "quickly" picked up by KVM/Get, then you should set the ExpiryTimeInSecs to be "relatively low".... Exact meaning of "quick" and "low" are up to you to decide. It could be 10 seconds, 30 seconds,... you choose. If you have o(100) transactions a second, the choice of cache lifetime will not be critical to the performance of the proxy. If you have o(5000) transactions per second, the choice of expiry of the cache will have more impact. In cases where I wanted admin changes to be effective relatively quickly, with low transaction volumes, I use an expiry time of 10-30 seconds. But as always, for performance sensitive systems, the best way to determine the correct setting is to test the H*** out of it.

Thanks @Dino. Nicely explained.

Follow up question, Is there anyway i can tell MP that cache is updated. Go ahead and refresh it. Can't we do it through mgmt API?