You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/actions.md
+78Lines changed: 78 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -82,6 +82,84 @@ You can create a new runtime in two ways:
82
82
Follow the instructions in [Updating Action Language Runtimes](actions-update.md) for updating, removing or renaming
83
83
runtime kinds or language families.
84
84
85
+
### How prewarm containers are provisioned without a reactive configuration
86
+
87
+
Prewarmed containers are created when an invoker starts, they are created according to runtimes.json's stemCells, e.g.
88
+
```
89
+
{
90
+
"kind": "nodejs:14",
91
+
"default": true,
92
+
"image": {
93
+
"prefix": "openwhisk",
94
+
"name": "action-nodejs-v14",
95
+
"tag": "nightly"
96
+
},
97
+
"deprecated": false,
98
+
"attached": {
99
+
"attachmentName": "codefile",
100
+
"attachmentType": "text/plain"
101
+
},
102
+
"stemCells": [
103
+
{
104
+
"initialCount": 2,
105
+
"memory": "256 MB"
106
+
}
107
+
]
108
+
}
109
+
```
110
+
In the above example, there is only one runtime configuration, which is `nodejs:14`.
111
+
It has a stem cell configuration and 2 containers with 256MB memory for `nodejs:14` will be provisioned when an invoker starts.
112
+
When an activation with the `nodejs:14` kind arrives, one of the prewarm containers can be used to alleviate a cold start.
113
+
A prewarm container that is assigned to an action is moved to the busy pool and the invoker creates one more prewarm container to replenish the prewarm pool.
114
+
In this way, when no reactive configuration is configured, an invoker always maintains the same number of prewarm containers.
115
+
116
+
### How prewarmed containers are provisioned with a reactive configuration
117
+
118
+
With a reactive configuration, the number of prewarm containers is dynamically controlled, e.g.
119
+
```
120
+
{
121
+
"kind": "nodejs:14",
122
+
"default": true,
123
+
"image": {
124
+
"prefix": "openwhisk",
125
+
"name": "action-nodejs-v14",
126
+
"tag": "nightly"
127
+
},
128
+
"deprecated": false,
129
+
"attached": {
130
+
"attachmentName": "codefile",
131
+
"attachmentType": "text/plain"
132
+
},
133
+
"stemCells": [
134
+
{
135
+
"initialCount": 2,
136
+
"memory": "256 MB",
137
+
"reactive": {
138
+
"minCount": 1,
139
+
"maxCount": 4,
140
+
"ttl": "2 minutes",
141
+
"threshold": 2,
142
+
"increment": 1
143
+
}
144
+
]
145
+
}
146
+
```
147
+
In the above example, there is a reactive configuration for `nodejs:14` and there are 4 underlying configurations.
148
+
*`minCount`: the minimum number of prewarm containers. The number of prewarm containers can't be fewer than this value
149
+
*`maxCount`: the maximum number of prewarm containers. The number of prewarm containers cannot exceed this value
150
+
*`ttl`: the amount of time that prewarm containers can exist without any activation. If no activation for the prewarm container arrives in the given time, the prewarm container will be removed
151
+
*`threshold` and `increment`: these two configurations control the number of new prewarm containers to be created.
152
+
153
+
The number of prewarmed containers is dynamically controlled when:
154
+
* they are expired due to a TTL, some prewarmed containers are removed to save resources.
155
+
* cold starts happen, some prewarm containers are created according to the following calculus.
156
+
-`# of prewarm containers to be created` = `# of cold starts` / `threshold` * `increment`
0 commit comments