The main instrument you can use for tuning how a given action is executed and enable a faster number of executions, is the value you set for the action/container concurrency. This value is not related to the concurrent value per namespace or minuteRate value, though these two enforce the upper limit for actions executed per minute your namespace can reach.
The default value is 200 and it means that 200 invocation can happen in the same container for the that action. Suppose that you want to execute 100 times a HelloWorld action at the same time or in short period of time (minutes). With the default value (200) it means that the system will use 1 container instead of using up to 100 containers.
This enables you to avoid cold-start issues. When the system doesn’t have any containers left, it has to create new ones. This cold-start adds a lot of latency to your application.
You can set any value between 1 and 500. In the example below, the limit is set to 100:
wsk action create actionName fileName.js -c 100
Some considerations to keep in mind:
200. You should experiment to make sure the value you choose is workingA second way for maximizing your chances of having the best low latency possible is creating actions that use the default Node version and a memory setting that is 256MB, 512MB, or 1024MB - this way you avoid cold-starts in most cases.
The system has a pool of containers with these settings waiting to be used for any incoming call that can’t be sent to an existing running container and the action matches the container settings (Node version and memory setting). In this scenario, time will only be spent for injecting your action code as opposed to wait for creating a container first and then get the code injected.
The second instrument you have to maximize throughput is caching the action response. When you cache an action response, for the time the cache is valid, you can invoke the action without increasing the counter used by minuteRate or concurrent action invocations per namespace. In this situations, your action is not actually executed, instead the system serves the result from cache.
You use the Cache-Control directive in order to configure the cache. Below is an example of an action that sets the cache with a TTL of 30 minutes. In the response object you’ll find an entry with X-Cache: HIT or X-Cache: MISS (depending on the answer being returned from cache or not).
function main(args) {
return {
body: "OK",
statusCode: 200,
headers: {
"Cache-Control": "max-age=1800"
}
}
}
One way to verify if a response is returned from the cache or not is by checking for the following header:
X-GW-Cache: HIT
Note: Encoded responses can’t be cached, this means that
Content-Encodingresponse header needs to be always empty in order for the response to be cached.Vary Header
The caching layer supports the use of Vary header to enable caching based not only on URL and query parameters but on header fields.
For example you here is some action that responds to certain header fields when doing some complex calculation:
curl -H "storeId: 1234" https://runtime-namespace-1.adobeioruntime.net/api/v1/web/store?query={products(pageSize: 10,filter:{ id:{ eq:"abcedefg"}}){items{name}}}
Could produce a response:
HTTP/1.1 200 OK
Content-Type: application/json
Vary: storeId
Cache-Control: max-age=120
X-GW-Cache: MISS
{"someBigData" : ["array"]}
That would add the storeId to the cache key such that subsequent requests with the same storeId in the headers will create a HIT up till the cahe control header settings and anytime the value varies, it will be a MISS and be stored under a new key with new cache control directives.